feat(transport): bearer transport on the auth routes and POST /refresh

[Bccorb]

Summary

Stacked on #162 (merge that first; this PR's base will then be retargeted to main). Closes #163. Part of the mobile track fells-code/seamless-templates#40.

Every proxied /auth/* route assumed cookies. A native client has no cookie jar, so it could not sign in through the adapter, and going around it to the auth API directly would bypass message delivery (adopter templates), client IP / user agent forwarding, and the service token, and would need the auth API exposed.

A request that carries x-seamless-auth-transport: bearer now gets a bearer contract on the same routes:

• The client presents the token a route needs in Authorization: Bearer (the ephemeral token /login or /registration/register returned on pre-auth routes, the access token on access routes). The adapter forwards it to the auth API as-is; the auth API decides whether it is the right kind for the route.
• Session-issuing responses come back whole, token and refreshToken included, with no Set-Cookie. The auth API's RS256 signature on the access token is still verified before the body goes out (sessionResult).
• ensureCookies is skipped. A route that needs an identity and gets no bearer token answers 401 with the same error a missing cookie gets.
• The header, not the presence of Authorization, selects the transport, because the first request of a flow carries no token in either. Requests without the header are served exactly as before (the whole existing suite passes untouched).

POST /refresh is new in both adapters:

• Bearer: Authorization: Bearer <refreshToken> in, rotated pair out. The auth API's failure body passes through so a client can tell refresh_token_reused (chain revoked, sign in again) from a transient error. Concurrent rotations of the same token are collapsed into one upstream call and a straggler within 5s gets the same pair, since the auth API treats a replayed refresh token as theft.
• Cookie: rotates the refresh cookie into fresh session cookies via the existing refreshAccessToken dedupe.

Core surface

AuthTransport, resolveAuthTransport, AUTH_TRANSPORT_HEADER, BEARER_TRANSPORT, sessionResult, transport option on loginHandler, registerHandler, finishLoginHandler, OTP verify handlers, pollMagicLinkConfirmationHandler, switchOrganizationHandler, finishOAuthLoginHandler; transport + authorization on checkProxyIdentity; transport on applyResult; refreshBearerSession; refreshHandler.

Security notes

• Bearer mode writes no cookies at all, including clears, so a browser cannot be talked into a cookie-less state by a header.
• Upstream session bodies are verified (signature, issuer, audience, subject match) before passthrough, same check as cookie minting.
• Failed refreshes are never cached; successes are cached 5s keyed by the raw refresh token (memory only, pruned and capped like the cookie path).
• originGuard is unchanged; it is inert for native clients (no Origin / Sec-Fetch-Site).

Test plan

• pnpm -r test: core 304, express 183, fastify 100 passing
• New: core/tests/transport.test.js (transport resolution, identity check, applyResult, sessionResult, refreshBearerSession dedupe and failure passthrough), fastify/tests/bearerTransport.parity.test.js (full bearer sign-in through both adapters: login, OTP verify, me, refresh, reuse failure, logout, proxied route, cookie jar untouched; both adapters held to the same answer), express/tests/refreshRoute.test.js (cookie-mode /refresh)
• Existing cookie-path tests unchanged and passing

Follow-ups

• @seamless-auth/client bearer transport in the React SDK monorepo consumes this contract.
• seamless-templates API starters pass authServerUrl/audience into requireAuth.