feat(routes): declare adapter behaviour in defineRoute and publish an adapter manifest

[Bccorb]

Part of #371. Closes #372.

Why

Server adapters hard-code per-route knowledge: which token a route takes, and which tokens a response issues or clears. In seamless-auth-server that is seven files per new route, the Express and Fastify adapters have drifted before, and a Go, Rust or Python adapter would have to copy all of it. This makes the API the source of that knowledge so adapters follow data instead.

What changes

• adapter option on defineRoute. Access routes default to an exposed passthrough that sends the access token, so most routes need nothing. The routes that differ declare credential, issues, clears, body.pick (adapter cookie transport only) and delivery. The API itself stays bearer and JSON only.
• Rules checked at registration, in the same spirit as the decoy check:
  • a public route must say whether adapters expose it (adapter: false or an object)
  • an ephemeral route must name preAuth or registration
  • a credential must fit the route's scope
  • a route that always returns a token must declare what it issues
• GET /.well-known/seamless-adapter.json serves the manifest (schemaVersion: 1). npm run generate:api also writes it to adapter-manifest.json, and a test keeps the committed copy in step. Health, JWKS, the manifest itself and the conformance routes are adapter: false.
• POST for the four OTP send routes and the magic-link request. They send a message, and the SDK already calls them with POST so a cross-site page cannot trigger them without a CORS preflight. A generic adapter following the manifest would otherwise have exposed GET. The GET forms keep working, are marked deprecated, and are not in the manifest.

/login keeps its narrowed body (message, identifierType, loginMethods).

Contract impact

Additive: one new endpoint, five new POST routes, five GET routes deprecated. No existing route changes shape. Consumers:

• feat(core): drive the proxy and cookie handling from the API adapter manifest seamless-auth-server#201 replaces the per-route handlers and the ensureCookies map with a proxy driven by this manifest.
• The Go, Rust and Python adapters (feat: Go server adapter (net/http, Gin) #373, feat: Rust server adapter for Axum #378, feat: Python server adapter for FastAPI and Django #379) are built on it.

Found while mapping the adapter

These are for fells-code/seamless-auth-server#201 and are not changed here:

• POST /totp/verify-login (TOTP sign-in) has no adapter passthrough, so TOTP sign-in does not work through an adapter today. It is in the manifest.
• The adapter exposes POST /users/update, which does not exist on the API.
• Under cookie transport the adapter passes the re-minted ephemeral token from the OTP send routes to the browser.

Checks

• npm run typecheck, npm run lint and npm run format:check are clean.
• npm run test:run: 135 files, 1795 passed.
• npm run build passes.
• A security review of the diff found no issues. It confirmed that adapter is metadata only, that the POST variants carry the same auth, decoy and limiter middleware, and that the manifest exposes nothing sensitive.