fix(#502): run mandatory authenticated-session teardown on involuntary auth loss too

[BorisTyshkevich]

What & why

Closes #502.

app.signOut documents and enforces an ordering invariant: cancel/tear down
every in-flight authenticated operation (Workbench request + server-side
KILL QUERY, schema graph, both export modes, catalog) and close the
documentation pane, all before clearing credentials and rendering the
login screen. The involuntary auth-loss path (onAuthLost, reached via
chCtx.onSignedOut) only rendered login — none of that teardown ran.

This factors the teardown into one idempotent teardownAuthenticatedSession()
in src/ui/app.ts, shared by app.signOut and the onAuthLost callback.

Three rounds of fixes were needed in src/application/connection-session.ts
beyond the app.ts wiring — each caught by an independent review pass, not by
me alone. Recording the full chain here since two of the three attempts
looked complete and weren't:

1. Reordering alone wasn't enough. chCtx.onSignedOut calls
   deps.onAuthLost(...) before clearTokens(), not after.

2. That reorder never even applied to the "failed refresh" trigger
   (one of onAuthLost bypasses mandatory authenticated-session teardown #502's own three listed triggers): getToken() was clearing
   credentials itself, synchronously, before its caller ever invoked
   onSignedOut. Moved that clearing out of getToken() — it's now solely
   onSignedOut's job. This alone still didn't fix the underlying problem
   (see feat(editor): consistent schema gestures, SQL formatter, undo-friendly inserts #3) and opened a reentrancy hole, closed with a signedOutHandled
   latch (first report runs the teardown, concurrent/nested reports no-op,
   reset only by a genuine fresh sign-in).

3. Removing that early clear still didn't make KILL QUERY reach the
   server. getToken() itself returns null whenever its own proactive
   refresh fails, independent of whether it also clears storage — so every
   nested authedFetch inside the teardown still saw !token and bailed
   before ever building a request. Fixed by having onSignedOut temporarily
   freeze chCtx.getToken to resolve the retained credential directly (no
   refresh, no expiry check) for its own synchronous duration, restoring the
   real function afterward. This works only because authedFetch reads and
   calls ctx.getToken synchronously, before its own first await — every
   nested fire-and-forget call captures the frozen value before the
   finally restores it.

   I initially also froze chCtx.authHeader/chCtx.refresh the same way,
   believing it would retroactively close Basic-mode teardown requests (KILL QUERY/export-cancel) get the wrong Authorization scheme after credentials clear #520 (a Basic-mode session's
   authHeader() reading authMode after it's been reset). That was wrong,
   caught by yet another review pass: authedFetch reads authHeader
   (and calls refresh, on an actual 401) only in the continuation after
   its own getToken await — well after onSignedOut has already
   restored/cleared everything — so freezing them was dead code with no
   protective effect. Removed. Basic-mode teardown requests (KILL QUERY/export-cancel) get the wrong Authorization scheme after credentials clear #520 remains genuinely open, not fixed by
   this PR; a real fix needs the fire-and-forget calls awaited (or their
   credentials threaded through explicitly) before onSignedOut restores or
   clears anything — out of scope here.

4. onSignedOut also wraps deps.onAuthLost(...) in a try/finally so a
   throwing injected callback can't skip credential cleanup.

Fixed for real, not filed as inbox: src/ui/results.ts's detached/
expanded-view refresh preflight called ensureFreshToken() but never
reported the failure to onSignedOut at all — a real regression from step 2
above (getToken()'s own clearTokens() used to at least silently wipe
storage on this path; removing it left credentials lingering indefinitely if
this was a user's only live activity). ResultsApp.conn's type now also
carries chCtx.onSignedOut, and the failure branch calls it. Closes #522.

Filed #520 (inbox) — pre-existing, narrower Basic-mode gap described
above, predates this change and remains unfixed by it.

Tests

• chCtx.onSignedOut() on a deferred Workbench request aborts its signal and
  kills its server-side query, exactly like signOut(); graph, both export
  modes, the catalog, and the doc pane are torn down the same way.
• Resolving that request afterward records no History entry, no successful-
  result columns, no bound-parameter recording, and no schema reload.
• A token that needed (and failed) a proactive refresh still gets its
  KILL QUERY sent using the retained credential, at both the
  connection-session unit level and the full app integration level.
• A second report for the same dead session is a no-op (latch); a fresh
  sign-in resets it so a later distinct auth loss is handled again.
• Credentials are still fully cleared even when the injected onAuthLost
  throws.
• The detached/expanded Data Pane view's own refresh failure now reports
  auth loss too.
• The existing 401/403-after-authConfirmed "stays a query error" contract
  is untouched (no changes to src/net/ch-client.ts) and still covered by
  its own tests.

Checklist

• npm test passes (the per-file coverage gate is non-negotiable)
• Tests added/updated in the same change as the code
• npm run build succeeds (single-file dist/sql.html)
• Layers kept honest: pure logic in src/core/, network in src/net/ (injected fetch), DOM in src/ui/
• No new runtime dependency
• README / CHANGELOG.md ([Unreleased]) updated
• Reconciled affected tracked work — not part of any roadmap track; closed Detached-view (Data Pane Expand) refresh failure never reports auth loss #522, filed/left open Basic-mode teardown requests (KILL QUERY/export-cancel) get the wrong Authorization scheme after credentials clear #520 (inbox)

[BorisTyshkevich]

Superseded by merged #524, which carries this teardown/race evidence into the authenticated execution-scope design for #512.