Explain OAuth client scope consent errors

[niemyjski]

MCP consent discarded OAuth error descriptions from HTTP 400 responses because FetchClient puts non-success JSON in problem. Show those descriptions through the existing shared Problem Details helper, name only known disallowed scopes, and make the fallback match the server’s optional offline access.

Scope and organization selections now stay disabled until consent validation succeeds and while approval is submitted. Each new authorization query requires fresh validation; overlapping responses cannot overwrite the current request, including navigation back to an identical query. Current-route documentation explains scope meanings and the distinction between client registration settings and user grants.

Closes #2615. Registration defaults and authorization enforcement are unchanged.

Verification at 8d9db6bff8461a23138f36daa4434ac13dac567c:

• Six new regression failures reproduced before the follow-up fix; all 1,024 frontend unit tests now pass.
• npm run validate: zero Svelte errors/warnings; formatting and lint pass. Production build passes.
• Local Chromium consent regression passes without retries. It covers failed/pending controls, restart, final OAuth errors, and A → B → A navigation using real FetchClient handling of isolated HTTP responses.
• Removing only the request-ID guard makes the identical-query regression fail; restoring the reviewed source passes.
• Independent Astra review of this exact commit: no blocking findings.
• Build CI for this commit passes: 3,153 backend tests, 1,024 frontend tests and 118 browser tests. Three unrelated backend tests are skipped. All 82 OAuth endpoint cases, 13 client-administration cases and 19 scope/identity cases pass.
• The live browser journey through registration editing, member consent, PKCE exchange and refresh passes on its first attempt in 11.7 seconds, with no mocked OAuth responses. All browser shards complete without retries.

The reporter’s original registration payload is unknown. Optional standalone strict E2E typechecking still reports the existing optional-email error in e2e/fixtures/api-client.ts:218; the changed tests introduce no additional errors. Local Docker remains unavailable; the live service journey was verified against this commit’s hosted services.

[github-actions]

Package	Line Rate	Branch Rate	Complexity	Health
Exceptionless.AppHost	23%	23%	128	❌
Exceptionless.Core	77%	68%	10827	✔
Exceptionless.Insulation	51%	43%	370	➖
Exceptionless.Web	86%	70%	9173	✔
Summary	80% (27827 / 34878)	69% (13762 / 20068)	20498	✔