fix: preserve Response enumerability, refresh transport docs (#2319 round 12)

Copying url/redirected/type onto the rebuilt response as enumerable own
properties changed what a consumer sees: `Object.keys`, object spread
and `JSON.stringify` are all affected. Which answer is correct turns
out to be the host's business — under the Fetch standard these are
prototype getters with no own enumerable key, while happy-dom defines
them as own enumerable data properties — so the descriptor is copied
from the freshly built Response rather than either answer being
hardcoded. The test compares against a baseline built in the same
runtime for the same reason.

Three comments still described the transport fetch as unbounded, which
round 11 changed:

- the wrapper's own docblock said it must never wrap the transport,
  obscuring that isExempt is what makes doing so safe;
- the auth-chain comment in inspectorClient repeated it;
- buildEffectiveAuthFetch's docblock said transport-internal discovery
  is not covered by a deadline.

All three now state the real distinction — both chains are bounded, and
they differ only in that the transport chain exempts the MCP endpoint —
and the docblock says why reusing the transport chain here would be
wrong rather than merely different.

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

clients/web/src/test/core/auth/requestTimeout.test.ts

@@ -305,6 +305,16 @@ describe("withOAuthRequestTimeout", () => {
     expect(response.url).toBe("https://as.example.com/redirected");
     expect(response.redirected).toBe(true);
     expect(response.type).toBe("cors");
+    // The rebuild must not change what enumerates. Which keys a `Response` owns
+    // is the host's business — under the Fetch standard these three are
+    // prototype getters and a native response has no own enumerable keys, while
+    // happy-dom makes them own enumerable data properties — so this compares
+    // against a baseline built in the same runtime rather than asserting either
+    // answer. Hard-coding one would make the rebuilt response observably
+    // different from a response that never passed through the wrapper, in
+    // `Object.keys`, object spread and `JSON.stringify`.
+    const baseline = Object.keys(new Response("{}")).sort();
+    expect(Object.keys(response).sort()).toEqual(baseline);
     await expect(response.json()).resolves.toEqual({
       issuer: "https://as.example.com",
     });