Fix MCP registry fetch blocking startup

[dmitrivMS]

Fixes #315314

The built-in defaultAccount provider blocks workbench startup with the MCP registry fetch when:

1. The user's Copilot token has mcp=1 enabled, but
2. Their account has no registry provisioned (endpoint returns 404).

Two things make this worse than it has to be:

• The fetch is awaited inline as part of init(), so it sits in the renderer's critical path.
• The shared request() helper retries 401/404 across every authenticated GitHub session — so a single registry call fans out into 3+ sequential requests for users with multiple accounts (~500ms each, hence the "VERY LONG TASK 536ms / 494ms" warnings in the report).

Changes

1. Don't fan out 404 responses across sessions for the MCP endpoint. A 404 here means "no registry provisioned for this account" — not a permissions/scope problem with the current session — so retrying other sessions just adds latency. Implemented as a new retryOn404 option on the shared request() helper (defaults to existing behavior; only the MCP path passes false). 401 retry is preserved.
2. Don't block startup on the MCP fetch. getDefaultAccountFromAuthenticatedSessions returns immediately with the cached MCP registry value, and refreshMcpRegistryInBackground performs the network round-trip and fires onDidChangePolicyData when it resolves. The background path drops the result if the active account changed in the meantime.
3. Honor forceRefresh. When the caller explicitly requests a fresh result (e.g. the Developer: Sync Account Policy command, forceResolveEntitlement), the MCP fetch is awaited inline so the returned data is genuinely fresh. Startup and event-driven refreshes (no forceRefresh) take the non-blocking path.

Reactive consumers — the ChatMCP and McpGalleryServiceUrl policy bindings in chat.contribution.ts — re-evaluate on onDidChangePolicyData, so they pick up the background refresh result automatically.

Expected impact

Scenario	Before	After
Cold start, no cached registry, 3 GitHub sessions	~1.5s blocking (3 × ~500ms)	0ms blocking, single bg request
Cold start, 1 session	~500ms blocking	0ms blocking
Subsequent startup with stale cache	Same blocking on every poll	Cached value used immediately, bg refresh
Developer: Sync Account Policy	Awaited inline	Awaited inline (unchanged)

The two VERY LONG TASK (536ms / 494ms) warnings in the report should disappear, and the "UI freezing for 1-2 seconds on every startup" symptom is removed.

Notes

The CPU profile attached to the issue (renderer-86585e.cpuprofile.json) does not contain the MCP-blocking task — the capture window appears to start after the freeze. The bug is corroborated by the reporter's other evidence (three GET .../copilot/mcp_registry 404 console entries, two VERY LONG TASK warnings matching expected request latency, and a stack trace through requestMcpRegistryProvider → getMcpRegistryProvider → getDefaultAccountFromAuthenticatedSessions) and by reading the code path.

This complements the prior fix in #306467, which already gated the MCP fetch on mcp=1 in the Copilot token. This PR addresses the remaining case where the token has mcp=1 but no registry endpoint is provisioned for the account.

[Copilot]

Pull request overview

Adjusts the default account MCP registry caching behavior to reduce renderer startup stalls caused by repeated sequential 404/empty responses from the GitHub MCP registry endpoint.

Changes:

• Introduces a 24-hour negative-cache interval for MCP registry lookups when the last fetch yielded no registry URL.
• Adds isMcpRegistryDataStale to choose between the standard 1-hour window and the new negative-cache window.
• Updates getMcpRegistryProvider to use the MCP-specific staleness logic.

Show a summary per file

File	Description
src/vs/workbench/services/accounts/browser/defaultAccount.ts	Extends MCP registry negative caching to 24h and centralizes the staleness decision in a helper to avoid repeated 404 fetches during startup.

Copilot's findings

• Files reviewed: 1/1 changed files
• Comments generated: 1

[github-actions]

blocks-ci screenshots changed

Replace the contents of test/componentFixtures/blocks-ci-screenshots.md with:

Updated blocks-ci-screenshots.md

<!-- auto-generated by CI — do not edit manually -->

#### editor/codeEditor/CodeEditor/Dark
![screenshot](https://hediet-screenshots.azurewebsites.net/images/67bfb687fd2818bd53771a60660541b9ed6f38b80d37da0aac15d267ecaeacec)

#### editor/codeEditor/CodeEditor/Light
![screenshot](https://hediet-screenshots.azurewebsites.net/images/0469dd8d0a587d94a1eaec514c79917b93b9a38694ef2b767bb1892819ae0a55)

#### editor/inlineChatZoneWidget/InlineChatZoneWidget/Dark
![screenshot](https://hediet-screenshots.azurewebsites.net/images/97162fc53c861ee13dc78a18e41fe3a25a42f62dc52a560510ebf084a418e1c3)

#### editor/inlineChatZoneWidget/InlineChatZoneWidget/Light
![screenshot](https://hediet-screenshots.azurewebsites.net/images/3b7e2eb5cc9ba727e2bc1c5113c3e17d8e9a6ce9a37b77519be3716ceb9a9afa)

#### editor/inlineChatZoneWidget/InlineChatZoneWidgetTerminated/Dark
![screenshot](https://hediet-screenshots.azurewebsites.net/images/97162fc53c861ee13dc78a18e41fe3a25a42f62dc52a560510ebf084a418e1c3)

#### editor/inlineChatZoneWidget/InlineChatZoneWidgetTerminated/Light
![screenshot](https://hediet-screenshots.azurewebsites.net/images/3b7e2eb5cc9ba727e2bc1c5113c3e17d8e9a6ce9a37b77519be3716ceb9a9afa)