fix(oauth): walk the candidates in the CLI refresh path too

Copilot review round 1.

`refreshStoredAuthToken` consumes the same fallback and made a single SDK
discovery call, so preserving the path there — without the walk the other two
consumers got — would have regressed exactly the case the walk exists to keep:
a path-hosted MCP server whose authorization metadata is published at the
domain root.

It injects its own discovery function as a test seam, so the walk is now also
exposed as `discoverAuthorizationServerMetadataFromCandidates(candidates,
discover)`, which takes that function and reports *which* candidate answered —
the CLI needs the winning URL, since it is the base the token request is made
against, not just the metadata.

Also drops the `as unknown as typeof fetch` from the new test in favour of
`vi.fn<typeof fetch>()`.

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

clients/web/src/test/integration/auth/discovery.test.ts

@@ -473,12 +473,12 @@ describe("path-hosted MCP servers (#2110)", () => {
       vi.mocked(discoverAuthorizationServerMetadata).mockResolvedValue(
         undefined,
       );
-      const fetchFn = vi.fn();
+      const fetchFn = vi.fn<typeof fetch>();
 
       await discoverAuthorizationServerMetadataForServer(
         pathServerUrl,
         undefined,
-        fetchFn as unknown as typeof fetch,
+        fetchFn,
       );
 
       expect(discoverAuthorizationServerMetadata).toHaveBeenCalledWith(