New /v1/person/proposals endpoint

[Aditi Chikkali (AditiChikkali)]

This PR introduces a new proposals endpoint that returns proposals scoped to requesting username and current cycle.

Changes by File

1. proposal_model.py

• Added ProposalSummaryForUser model for proposal-level fields needed by the UI (proposal id, title, SAF ids, PI, instruments, cycles, data session).
• Added UserProposalsList wrapper model with username, count, current_cycle and proposals.

2. proposal_service.py

• Added fetch_proposals_for_username to return a tuple of current cycle and filtered proposals.
• Enforced filtering by both username and current operating cycle.
• Returns (None, []) when no current cycle exists, making no-cycle behavior explicit.

3. user_api.py

• Added /v1/person/proposals endpoint using new response model.
• Builds ProposalSummaryForUser entries from proposal documents.
• Returns 404 when no current operating cycle is available.

[Dan Allan (danielballan)]

I would help to zoom out from the mechanical summary of file changes above and get some context about motivation.

There are currently two related endpoints:

1. /proposals, which gives proposal details, optionally filtered in some ways, including by a given list of proposal IDs
2. /data-session/{username} which gives a list of proposals per user

To get proposal details for proposals that a user is listed on, one could fetch the IDs from (2) and pass those to (1) to obtain the details.

The proposed new endpoint in this PR makes it possible to achieve this in a single request. However, it lacks pagination. This could create a problem if the set of proposals is large.

Some options to consider:

• Instead of a new endpoint, add filtering by user to the existing endpoint. This would be have the advantage that the filtering could be combined with other conditions: "Find me proposals for User X for this cycle or _for this beamline/instrument."
• Keep the dedicated endpoint proposed here, but add pagination.