feat(server): mint session-scoped member tokens, release 0.0.4

[Dere-Wah]

Why

Member JWTs were unscoped: any admitted browser held a token with full user-level access to the queue's Reactor account — it could create sessions for any model, act on other sessions, and call non-session APIs. The Coordinator now supports session authorization_details on POST /tokens (reactor#3195–#3197, live on prod and dev): a scoped token may only create sessions for the matched model, up to max_sessions, and act on the sessions its own grant created. Anything else returns 403, and grant state is enforced server-side.

The constraint that shapes this change: a session is bound to the grant of the token that created it, at creation time only. A token minted later can never attach to an existing session. So the queue can't keep creating sessions with its own server JWT and hand members separate scoped tokens — the member's token has to be the one that created the session.

What Changed

The scoped token belongs to the slot, not the member. Each slot mints one scoped token (match: [model], max_sessions: 1) the first time it needs one; the slot's session is created with that token — the binding step — and every member seated on the slot receives it. That keeps the whole placement model intact: shared sessions (usersPerSession > 1) work because members of a slot share its token, and the connection-cap spill path works because a member who lands on a different slot is re-sent that slot's token just before session_ready.

Scoped tokens cannot be refreshed mid-session (a re-mint starts a new, empty grant), so slot tokens are minted to cover the admission grace plus the full session budget, with tokenTtlSeconds acting as a floor; request_token / the getJwt resolver re-deliver the stored token instead of minting. The queue's own admin JWT stays unscoped — polling GET .../runtime and DELETE /sessions/{id} across slots rides on same-user ownership, which the enforcement deliberately leaves intact.

Two paths intentionally keep the old unscoped member tokens: deployments with an acquireSession override (their sessions are bound to no grant this server holds), and slots persisted by a previous version whose session already exists without a stored token — so a rolling deploy over live rooms degrades gracefully instead of locking members out.

On the wire nothing changes: clients still receive { type: "token", jwt, expiresAt } and attach with connect({ sessionId, connectionId }). No client/react/admin surface changes.

The package version moves to 0.0.4, so merging this releases it (release.yml keys off the version).

Verification

pnpm typecheck, pnpm test (126 tests, including new coverage: scope payload + TTL floor at mint, session/connection created with the slot token, token re-delivery without re-mint, shared-slot token reuse, spill re-send, acquireSession fallback, legacy grant-less slot fallback), pnpm format:check, pnpm lint:license.

Coordinator behavior backing the design was verified live against prod: scoped mint echoes canonical authorization_details; scoped JWTs 403 on unmatched models, non-session APIs, and other tokens' sessions; unscoped same-key tokens retain ownership access to scoped-created sessions.

Made with Cursor