fix(auth): address review — proxy CIMD discovery fetch, validate metadata path

Two findings from review:

- `ensureCimdClientRegistration` ran protected-resource discovery on the
  global fetch while its AS-metadata leg used the configured one. On web
  that is `createRemoteFetch`, which proxies through the backend to sidestep
  CORS — so the discovery this PR routes to a challenge-advertised URL would
  fail in the browser, be swallowed by the catch, and leave CIMD probing the
  wrong authorization server. Forward `params.fetchFn`, and assert in the
  test that nothing reaches the global.

- `oauth.resourceMetadataPath` accepted `//other-host/doc`. Resolved against
  the request base that re-points the origin in the advertised
  `resource_metadata` while Express still registers the route locally, so the
  server would advertise a document it does not serve. `/\\host` does the
  same, since the URL parser folds a backslash into a slash for special
  schemes — a leading-slash check misses both. Validate origin-relativity
  with a shared predicate, used by the JSON-config validator and again at
  server setup for a programmatically built ServerConfig.

Signed-off-by: cliffhall <cliff@futurescale.com>

core/auth/cimd.ts

@@ -38,6 +38,12 @@ export async function ensureCimdClientRegistration(params: {
     resourceMetadata = await discoverOAuthProtectedResourceMetadata(
       params.serverUrl,
       { resourceMetadataUrl: params.resourceMetadataUrl },
+      // The same fetch the AS-metadata leg below uses. On web that is
+      // `createRemoteFetch`, which proxies through the backend to sidestep
+      // CORS — on the global `fetch` this leg would fail in the browser, be
+      // swallowed by the catch, and leave CIMD probing the wrong
+      // authorization server (Copilot).
+      params.fetchFn,
     );
   } catch {
     resourceMetadata = undefined;