Scaffold a FastAPI endpoint with real validation and status codes

Scaffold one FastAPI endpoint. This is a real service route, not a toy example — include validation, correct status codes, and dependency injection, the way it would actually ship.

ENDPOINT REQUIREMENT
POST a new subscription for a user: takes plan_id and payment_method_id, returns the created subscription, 404 if plan_id doesn't exist, 409 if the user already has an active subscription.

CONVENTIONS TO FOLLOW
- Use APIRouter, mounted under /api/v1, resource name subscriptions.
- Request and response bodies are Pydantic v2 models (BaseModel, not raw dicts) with Field constraints matching the requirement — don't accept a wider type than the spec allows.
- Use response_model on the route decorator, and the correct status code from fastapi.status (201 for creation, 204 for delete with no body, 404 when a lookup fails — 422 is Pydantic's job to raise automatically, not yours to hand-roll).
- Inject dependencies (DB session, current user, rate limiter, etc.) via Depends(...), never instantiate them inside the handler. Assume this dependency already exists and is wired: get_db_session() -> AsyncSession, already defined in app/api/deps.py.
- Auth: requires an authenticated user via get_current_user(). If it's "none," don't add an auth dependency; don't invent one either just because most routes in a typical app have one.
- All I/O is async def. If a called function is genuinely synchronous or CPU-bound, say so explicitly and wrap it with run_in_threadpool rather than blocking the event loop silently inside an async handler.
- Raise HTTPException with a specific status and a specific detail message for every failure path named in the requirement — don't let an unhandled case fall through to a generic 500 that tells the caller nothing.
- Concurrency edge case: Two requests from the same user could both pass the "no active subscription" check before either commits, creating two active subscriptions.. If two requests could race on the same resource, say explicitly what prevents a lost update or duplicate row, rather than assuming single-request timing.
- Pagination: if the endpoint returns a list, use limit/offset or cursor-based pagination matching the resource's expected size, and cap the maximum page size server-side — never trust a client-supplied limit as unbounded, since that turns one request into an accidental full-table scan.
- Idempotency: if the requirement implies a client might retry the same request (anything payment-adjacent or otherwise non-idempotent), state whether an idempotency key is needed and exactly how it's checked before the write happens — silently allowing an identical retry to double-create or double-charge is a real design gap, not a rare edge case to wave off.

OUTPUT FORMAT
1. The Pydantic request/response models, with every Field constraint justified against the requirement.
2. The route function, fully wired with its dependencies.
3. A one-line note per status code used, mapping it to the exact requirement or failure path it satisfies.
4. One sentence on how Two requests from the same user could both pass the "no active subscription" check before either commits, creating two active subscriptions. is actually addressed, or a stated reason it isn't a real risk here.
5. One sentence on whether this endpoint needed pagination or idempotency handling, and what was done about it if so.