fix(cloud): require CSRF state in the WorkOS login callback

[ra-co88]

What

The WorkOS login callback now requires a valid, unconsumed CSRF state parameter on every request. Missing state, unknown state, or a replayed (already consumed) state each return 400 before any WorkOS API call is made.

Why

Login CSRF: an attacker can craft a callback URL that logs the victim into the attacker's account. The state parameter ties the callback to a login flow the user actually initiated — without enforcing it unconditionally, the callback accepts forged authorization codes. The check now happens before any network call to WorkOS, so forged requests are rejected at zero cost.

What changed

• The callback handler rejects requests with no state (400) before any WorkOS call.
• State values are single-use: a replayed state returns 400.
• A fresh state matching the browser's cookie proceeds to the session exchange (302).

Breaking changes

Flows that initiate login server-side and construct the callback URL without a state parameter will now be rejected. If you drive login from a server, generate a random nonce, persist it server-side (or sign it), and pass it as state — the callback validates it against the cookie it sets.

Test plan

Focused suite on the callback handler (apps/cloud/src/auth/workos-callback-state.node.test.ts):

• no state → 400, no WorkOS call issued
• replayed/consumed state → 400
• fresh state matching cookie → 302 + session

All green against current main.

[ra-co88]

Heads-up on the red E2E (cloud 13of16) check here: it's failing on main itself (e.g. the Version Packages runs), so it's pre-existing rather than from this PR. It's the cap-eviction scenario tripping over workerd resetting session Durable Objects mid-initialize when the test opens its burst of sessions — diagnosis and a proposed fix in #1895.

[ra-co88]

Superseded by the corrected review below (this one was posted with shell-mangled formatting). See the 07:28 UTC review for the actual verdict.

[ra-co88]

Verdict: approve — login-CSRF hardening, correctly implemented and tested. (Comment review: GitHub blocks formal self-approval on your own PR.)

Supersession check (upstream/main @ 2dc399e): the callback still only enforces state when present — the if (query.state !== undefined) guard allows a no-state entry path, which is precisely the login-CSRF hole this PR closes. Not superseded; the fix is genuinely missing upstream.

The change is the right shape:

• Unconditional state check before any WorkOS network call — forged callbacks now die at 400 with zero WorkOS cost, and the code comment documents the attack (attacker completes their own round-trip, victim gets signed into the attacker's account).
• Single-use contract preserved: the state cookie is consumed on use; the replay test at workos-callback-state.node.test.ts:150 drives a second callback with the same state and no cookie and asserts 400.
• Negative cases are real, not vacuous: node-level (replay ⇒ 400), e2e-level (login-csrf.test.ts:69 replayed GET ⇒ 400 "Invalid login state"), plus browser-binding and provider-redirect capture coverage. The negative-control discipline holds.
• Timing-safe comparison on the state match.

One honest caveat for the maintainer: the branch's diff footprint vs upstream is large (34 files) because it carries an old merge-base; the actual payload is 4a0c27e (the handler hardening) plus its test commits. The extra files (session-build-semaphore.test.ts, org-api-keys-console.test.ts) arrive via the stale base, not this PR's intent.

CI: all shards green (cloud 1-16, local, selfhost). Merges clean against current upstream/main.

Minor note: the missing-state case compares against the empty string rather than branching separately; fine, though a maintainer may prefer an explicit two-branch form for readability. Not blocking.