fix(auth): sign in via POST so link prefetches can't use magic links

[steadhac]

GET /auth/verify used to mark the magic-link token used and sign in whoever fetched it. Mail scanners, click trackers and link previews fetch links automatically, so they were signed in and the real user saw "Link expired".

• GET /auth/verify now only renders a confirmation page. Sign-in moves to POST /auth/verify.
• The token is claimed with a conditional update, so a link cannot be redeemed twice, and the claim is released if the session cannot be created, so a failed sign-in no longer burns the link.
• SessionMiddleware no longer overwrites a session cookie the route has already set. It re-set the cookie to the temporary session that signing in a returning user had just deleted, leaving them signed out.
• The auth funnel counts only POSTs to /auth/verify as verifications, since opening a link is now a separate GET.

Fixes #582
Fixes #583
Refs #541

Summary

Fixes two magic-link sign-in bugs:

• Bug_211_MUST_FIX: AUTH-QA-001 — GET /auth/verify consumes the token and signs in the requester, so any automated fetch locks the real user out and, on an account's first sign-in, takes it over #582 — GET /auth/verify marked the token used and signed in whoever fetched it. Mail scanners, click trackers and link previews fetch links automatically, so on an account's first sign-in they were signed in, and the real user saw "Link expired".
• Bug_212_MUST_FIX: AUTH-QA-007 — Returning users who open the magic link in a different browser are redirected to /portals but left signed out; the middleware overwrites their new session cookie with the temp session sign-in just deleted #583 — a returning user who opened the link in a different browser was redirected to /portals but left signed out, because the middleware overwrote the new session cookie with the temporary session that sign-in had just deleted.

Changes

File	Change
finbot/apps/finbot/auth.py	GET /auth/verify now only renders a confirmation page. Sign-in moves to POST /auth/verify. The token is claimed with a conditional update so a link can't be redeemed twice, and the claim is released if the session can't be created, so a failed sign-in no longer burns the link. The session-selection logic is unchanged.
finbot/apps/finbot/templates/auth-confirm.html	New "Confirm sign-in" page, styled like auth-error.html.
finbot/core/auth/middleware.py	Don't overwrite a session cookie the route has already set.
finbot/core/analytics/queries.py	The auth funnel counts only POST /auth/verify as verifications; opening a link is now a separate GET.
tests/integration/auth/test_magic_link_verify.py	12 new tests.

Testing

Automated — tests/integration/auth/test_magic_link_verify.py, 12 tests:

Code	Result
This branch	12 passed
Without the middleware change	1 failed — the #583 test
main	11 failed

Every test uses a freshly generated email address, and every retry uses a separate client. A same-client retry is short-circuited by _is_authenticated, and reused addresses take the returning-user path, both of which hide these bugs.

Full suite: 325 passed, 3 failed. The same 3 fail on main (tests/unit/agents/test_specialized_agents.py).

Manual, in two browsers against a local server:

Scenario	Before	After
Link fetched by curl first, then opened by the user	curl gets 303 and a session; user sees "Link expired"	curl gets the confirmation page; user signs in
Link opened but not confirmed	token used, signed in	token unused, still signed out
Same link used from a second browser	—	rejected
Returning user, different browser	redirected but signed out	signed in
Returning user, session cookie deleted before confirming	signed out, two Set-Cookie headers	signed in, one Set-Cookie (Max-Age=1209600)

Notes for reviewers

• Signing in takes one extra click. This is deliberate: an auto-submitting form would be completed by URL-detonation sandboxes that run JavaScript (see Bug_211_MUST_FIX: AUTH-QA-001 — GET /auth/verify consumes the token and signs in the requester, so any automated fetch locks the real user out and, on an account's first sign-in, takes it over #582, Option B).
• In the normal flow, the confirmation page gives the browser a session before it submits, so Bug_212_MUST_FIX: AUTH-QA-007 — Returning users who open the magic link in a different browser are redirected to /portals but left signed out; the middleware overwrites their new session cookie with the temp session sign-in just deleted #583 no longer triggers there on its own. The middleware change still matters when the submit arrives without a session — cookies cleared, or the session expired in between — which is what test_returning_user_signs_in_when_the_submit_has_no_session covers.
• Out of scope: a link that has already been used still shows "Link expired" rather than a used-link message.

[steadhac]

@saikishu PR for Fixes #582
Fixes #583