fix(auth): make snapshot-and-clear one atomic storage step (#2144)

Copilot review round 18. Three of its findings were the same check-then-act:
`planOAuthRevocation` is asynchronous, so the gap between its reads and the
following `storage.clear()` is still a window — shorter than the network one
closed in round 13, but the same shape. An OAuth completion landing at any of
those awaits saved a grant the clear then destroyed.

`OAuthStorage.takeRevocationSnapshot(serverUrl)` reads what revocation needs
and clears the server in ONE synchronous pass over the in-memory state, with
the persist after the mutation. `clearAndPlanRevocation` replaces
`planOAuthRevocation`, and there is no separate `clear` call left in any
caller — the clear cannot be forgotten or reordered.

The snapshot returns values unparsed, deliberately: schema validation is pure
and belongs after the mutation, since running it inside would reintroduce the
`await` this exists to remove.

Two consequences worth naming. A failure of the take-and-clear now REJECTS
rather than returning an outcome, because the state was not cleared and the
caller's contract is that it was; both clients already have a rejection path.
And cross-process atomicity is explicitly not claimed — nothing in this store
takes a lock, every mutation is a read-modify-write over a loaded snapshot, and
`clear` alone always had that property.

Also from round 18:

- The CLI's budget check ran before considering `plan.outcome`, so a key that
  needed no network was reported as budget-exhausted — warning that a grant may
  be live when that key held none.
- A disconnect failure after a successful clear was reported as "could not
  clear OAuth state" in both clients. It now goes to the disconnect channel,
  and the success is still reported.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0177mPHAdECD18nLLCTwR5rh
Signed-off-by: cliffhall <cliff@futurescale.com>

clients/web/src/lib/clearServerOAuthState.ts

@@ -1,6 +1,6 @@
 import {
+  clearAndPlanRevocation,
   executeOAuthRevocation,
-  planOAuthRevocation,
   type TokenRevocationOutcome,
 } from "@inspector/core/auth/revocation.js";
 import type { OAuthStorage } from "@inspector/core/auth/storage.js";
@@ -72,18 +72,17 @@ export async function clearServerOAuthState(
   // No proxied fetch on hand means no request we could usefully make, so the
   // leg is reported as skipped rather than attempted against the page origin.
   const fetchFn = params.fetchFn;
-  // Snapshot → clear → revoke. The clear must not wait on the network: this
-  // server can be inactive when the call starts and complete a *fresh*
-  // authorization while the request is in flight, at which point an unconditional
-  // clear afterwards would delete the new credentials. The session checks in
-  // `useOAuthRecovery` run after this helper returns and cannot protect the
-  // store, so the ordering is what does (#2144).
-  const plan = await planOAuthRevocation({
+  // Takes the state and deletes it in ONE atomic storage step, then sends. The
+  // clear must not wait on the network: this server can be inactive when the
+  // call starts and complete a *fresh* authorization while the request is in
+  // flight, at which point a later clear would delete the new credentials. The
+  // session checks in `useOAuthRecovery` run after this helper returns and
+  // cannot protect the store, so the ordering is what does (#2144).
+  const plan = await clearAndPlanRevocation({
     serverUrl,
     storage: params.oauthStorage,
     enabled: revoke && fetchFn !== undefined,
   });
-  await params.oauthStorage.clear(serverUrl);
   const revocation: TokenRevocationOutcome = fetchFn
     ? await executeOAuthRevocation(plan, { fetchFn })
     : { status: "skipped", reason: "disabled" };