fix(auth-core): make the fixation revoke fire on the form_post path (#36)

[ParallelEntrepreneur]

Closes #36. #44 documented this gap; this closes it, using option 1 from the issue — the one it called probably right.

The defect

issue revokes the session the browser was carrying before minting a new one, and it identified that session by the raw cookie the request presented:

if let Some(presented) = login.presented_cookie
    && let Some(old) = store::session_by_token_hash(db, &sha256_raw(presented.as_bytes())).await?

On Apple's form_post callback the session cookie is SameSite=Lax and is simply not sent with a cross-site POST. presented_cookie was therefore always None there, and the revoke could never fire for that provider — the superseded row stayed live server-side until it expired.

The fix

• Login gains presented_session_id, used when presented_cookie is None. The cookie stays the stronger evidence and wins when both are present.
• /start — which is same-site, so the cookie arrives there — seals the session id into the signed flow next to the user id it already sealed. The callback hands it back.

The id, not the value, and that is the design rather than an implementation detail: the value is a bearer credential, and a second copy of it inside another cookie widens its exposure for nothing. An id is useless without the row.

Breaking every call site was deliberate

Adding the field breaks all thirteen Login { .. } initializers rather than defaulting to None. Whether a login can name the session it replaces is a decision each path should make, and the compiler now forces it. The four same-site production paths — password login and registration, magic-link consume, passkey login — pass None with a one-line reason: their cookie arrives, so the stronger branch already handles them.

The test, and both ways it fails

My first attempt at this test passed vacuously in the wrong direction: I built a scenario that returned 200 OK without ever reaching issue, because the linking rules answered with a confirm-link page. Rewritten on the path that actually issues — two Apple sign-ins, the first session carried into the second /start — it asserts the old cookie no longer validates and that its row is marked revoked_at rather than merely orphaned.

I then broke each half of the chain and confirmed it catches both:

Broken	Result
issue ignores presented_session_id	FAILED — "the fixation revoke did not fire"
/start stops sealing the id	FAILED — same assertion

Meta

Gets the same wiring for symmetry, but its callback is a GET redirect, so its session cookie already arrives and the cookie branch wins. This is a fallback there that should not normally fire — I have not claimed it as a fix for Meta.

ADR 0102

Gains a dated update note. The paragraph describing the gap is left intact: it is an accurate record of the state between #35 and now, and rewriting it would erase why the decision was deferred.

397 tests, clippy --all-targets --all-features -D warnings, fmt, wasm32 workspace build.

🤖 Generated with Claude Code

https://claude.ai/code/session_01V8K9TBtmnf29dV6uEP5oM3