fix: usable IPv6 spelling, and drop a SEP label that means something else here (round 2)

- The recovery text told users to move the endpoint to `::1`. A bare IPv6
  literal is not a legal URL host — `new URL("http://::1/token")` throws — so
  anyone copying that into the Token URL override got a parse error from advice
  meant to unblock them. Now `[::1]`, in both the notice and the manual
  reproduction guide.

  The exemption list still reads `::1`, because that is the host the SDK
  compares; only the remedy is bracketed, because that is what a user types.
  The comment says so, so neither gets "corrected" into the other.

- Dropped SEP-2207 from all nine files it had reached. I took the label from
  the SDK's own source comments, which attribute this check to it — but this
  repo already uses SEP-2207 for OIDC refresh / offline_access
  (specification/v2_auth_hardening.md, plus an e2e test), so grepping it here
  would have turned up two unrelated things. Replaced with plain description
  rather than a different SEP number: having guessed wrong once, guessing again
  is not the fix.

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

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

@@ -467,6 +467,9 @@ describe("insecureTokenEndpoint copy", () => {
     expect(message).toContain(ENDPOINT);
     expect(message).toContain("HTTPS");
     expect(message).toContain("127.0.0.1");
+    // Bracketed: a bare IPv6 literal is not a legal URL host, so `::1` copied
+    // into the Token URL override would not parse.
+    expect(message).toContain("[::1]");
     expect(message).toContain("Token URL override");
     // The section name the UI actually renders. Sending someone to a settings
     // section that does not exist is the worst error this message could make.