Epic: adopt current HTTP API standards in /api/v1 #702

Description of Feature:

Bring /api/v1 in line with current HTTP API standards, so behaviour that today is Source-specific, or missing, follows a published RFC instead: conditional writes, authentication challenges, deprecation signals, API discovery, an OpenAPI 3.1 reference, and safe retries of creates.

This builds on answering every error as an RFC 9457 problem (#701, with source-cooperative/source-coop-cli#67 and source-cooperative/data.source.coop#263). In that change each kind of failure is defined once in src/lib/api/problems.ts, with an OperationError in src/lib/operations/result.ts to raise it, and is explained by a page at /api/problems/{code}. Every new status in this epic is a new entry in that table, not a status picked in a route.

What value is this feature adding to Source Cooperative?

Generic HTTP clients, the CLI and AI agents can rely on standard behaviour instead of learning Source's conventions. A client library that already handles ETag, WWW-Authenticate, Deprecation or Idempotency-Key works against Source without special cases, and an agent can find its way from one response to the next.

Scope

Each sub-issue updates API.md in the same PR, so the convention is codified where every route author reads it, and updates public/llms.txt and source-coop-cli where they are affected.

Watched but not planned yet

• RateLimit and RateLimit-Policy headers (draft-ietf-httpapi-ratelimit-headers). The latest revision is -11 (May 2026), still an Internet-Draft, and the HTTP directorate's early review of -10 found it not ready. Use Retry-After meanwhile.
• A rate_limited (429) problem with Retry-After. Nothing in the app throttles today, so this waits for the first thing that does: throttling for self sign-up, or the data proxy's abuse controls. When it lands it is a PROBLEMS entry plus Retry-After through problemResponse's headers argument, and the CLI retries once after a short Retry-After.
• The QUERY method (RFC 10008, June 2026): a good fit for product search, whose filters outgrow a query string. Next.js 15.5.9, the version installed here, dispatches a route handler only for GET, HEAD, OPTIONS, POST, PUT, DELETE and PATCH (HTTP_METHODS in next/dist/server/web/http.js), so a route can't export QUERY yet.
• Link: rel="next" (RFC 8288) next to next_cursor on every page, so a generic client can follow pages without knowing our body shape.
• W3C traceparent. Problems carry Vercel's x-vercel-id as request_id, and the data proxy uses x-request-id; traceparent would let one ID follow a request through both.
• RFC 9651 structured fields for any custom header we add.