Adds opt-in sync/stateless repository contracts for dynamic MCP server primitives:
tools, resources, prompts, and completions.

This is a narrower rework of #953 based on the design discussion in #578.

Motivation and Context

Some MCP servers need to expose different tools, resources, prompts, or completion
handlers depending on the authenticated user, tenant, token, headers, or other
request context.

This PR keeps the first repository shape narrow:

• repository contracts are synchronous and do not expose Mono<...>
• repositories are added only to the stateless sync server builder
• repository methods receive typed request inputs or identifiers plus
  McpTransportContext
• repository contracts do not expose server exchange objects
• list methods receive McpSchema.PaginatedRequest
• existing static registration APIs continue to work

Exchange-dependent flows such as sampling, elicitation, logging, and progress stay
on the existing handler API for now.

Design Notes

This PR follows the direction discussed in #578:

• Non-breaking opt-in: repositories are configured explicitly. Existing static
  registrations remain available.
• Stateless first: this starts with the sync/stateless shape instead of adding
  repository variants across the full server matrix.
• Sync public API: repository contracts are synchronous, while the current
  stateless async core adapts calls internally using the existing
  immediate-execution/offload model.
• Transport context instead of exchange: repositories receive
  McpTransportContext, keeping the API focused on request-context based discovery
  and execution.
• No implicit merging: static registrations and repositories cannot be
  configured together for the same primitive family.

How Has This Been Tested?

Added in-process stateless server tests for request-context based discovery and
resolution, completions, paginated list requests, runtime add/remove behavior, and
repository/static registration conflict validation.

I also tested the repository path locally with a small servlet server that resolves
primitives from request context.

Breaking Changes

None intended.

Existing static registration APIs continue to work. Repositories are opt-in and are
configured through the stateless sync server builder.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed