Session fixation revoke does not fire on the form_post callback path #36

Found in the Fable review of #35 (Apple sign-in), and deliberately not bodged there.

What

sessions::issue revokes the presented session before issuing a new one, as a fixation defence:

if let Some(presented) = login.presented_cookie
    && let Some(old) = store::session_by_token_hash(db, &sha256_raw(presented.as_bytes())).await?
{
    store::revoke_session(db, &old.id, &iso(clock.now())).await?;
}

That needs the raw cookie value. On a form_post callback (Apple) the session cookie is SameSite=Lax and does not arrive, so presented_cookie is always None and the revoke never runs.

#35 fixes the linking half of this by sealing the signed-in user id into the flow at /start (which is same-site, so the cookie does arrive there). It deliberately does not seal the cookie's value, because that is a bearer credential and putting it inside a second cookie widens its exposure for no clear gain.

Impact

Low. The person's previous session row stays live server-side until it expires, with no cookie pointing at it, because the browser has just overwritten it. It is untidy rather than exploitable: the cookie is __Host- and HttpOnly, so it cannot be planted cross-site, which is the attack the revoke exists for.

Options

1. Seal the session id (not its value) into the flow alongside the user id, and give Login a presented_session_id alternative to presented_cookie. Contained, and makes the revoke fire on every path.
2. Decide the revoke only meaningfully defends the paths where a cookie can be planted, and document that it does not apply to form_post.

Option 1 is probably right, but it changes auth-core's public API, which is why it is here rather than in #35.