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/test/integration/auth/revocation-e2e.test.ts

@@ -19,8 +19,8 @@ import {
 } from "@modelcontextprotocol/inspector-test-server";
 import { BrowserOAuthStorage } from "@inspector/core/auth/browser/storage.js";
 import {
+  clearAndPlanRevocation,
   executeOAuthRevocation,
-  planOAuthRevocation,
 } from "@inspector/core/auth/revocation.js";
 import type { TokenRevocationOutcome } from "@inspector/core/auth/revocation.js";
 import type { OAuthMetadata } from "@modelcontextprotocol/client";
@@ -203,14 +203,13 @@ describe("OAuth token revocation (RFC 7009)", () => {
   });
 
   /**
-   * The caller's real sequence — snapshot, clear, send — so this exercises the
-   * ordering the product uses rather than a convenience wrapper.
+   * The caller's real sequence — take-and-clear atomically, then send — so this
+   * exercises the ordering the product uses rather than a convenience wrapper.
    */
   async function clearAndRevoke(
     storage: BrowserOAuthStorage,
   ): Promise<TokenRevocationOutcome> {
-    const plan = await planOAuthRevocation({ serverUrl, storage });
-    await storage.clear(serverUrl);
+    const plan = await clearAndPlanRevocation({ serverUrl, storage });
     return executeOAuthRevocation(plan, { fetchFn: fetch });
   }