Resolve webview id for worker clients in service worker

[yongsooim]

Fixes #315494. This appears to be a regression from #311844.

processResourceRequest and processLocalhostRequest allow
worker / sharedworker clients past the guard, but neither function
routes them: the dispatch block runs only when webviewId is non-null,
and a worker client's client.url (typically
blob:https://<webview-origin>/<uuid>) has no id searchParam. The
request store entry is never resolved and the fetch hangs until
requestTimeout() fires; in the renderer this surfaces as
TypeError: Failed to fetch dynamically imported module.

This patch resolves the owning iframe for a worker client by matching
the worker URL's origin against window clients whose pathname is one of
the webview entry points, then reading id from that iframe's
searchParams. Because some webviews can intentionally share an origin,
the match is only accepted when that origin maps to a single webview id.
The relaxed worker / sharedworker exception in the guard is replaced:
a worker client whose owning iframe cannot be resolved unambiguously is
treated the same as a window client without a webview id (notFound()
for resource requests, fetch(event.request) for localhost), preserving
pre-#311844 behavior for that edge.

Validation

• node --check src/vs/workbench/contrib/webview/browser/pre/service-worker.js
• git diff --check
• Local service-worker VM mock:
  • upstream worker resource request sends no load-resource message
  • patched worker resource request sends load-resource
  • patched ambiguous shared-origin case fails closed
  • patched worker localhost request sends load-localhost

I did not run the full VS Code browser test suite from this sparse checkout.

[Copilot]

Pull request overview

Fixes a regression in the webview service worker where worker/sharedworker clients could pass the guard but fail routing due to lacking an id search param, causing fetches (notably dynamic imports) to hang until timeout.

Changes:

• Resolve a webview id for worker/sharedworker clients by mapping the worker URL origin to a single owning webview iframe client.
• Update processResourceRequest and processLocalhostRequest to use this worker resolution and fail closed when the owner cannot be resolved.
• Add getWebviewIdForWorkerClient helper to perform the origin-to-iframe-id resolution with ambiguity detection.

[yongsooim]

@microsoft-github-policy-service agree

[harshagarwalnyu]

I have refactored the service worker to address the code duplication concern raised by the AI reviewer. By extracting the path-checking logic into a helper function isWebviewIframe(url), we keep the logic DRY and reduce the risk of drift if entry points change. @yongsooim, feel free to pull these changes if you find them helpful!

[harshagarwalnyu]

I have opened a companion draft PR (#315498) that extracts the isWebviewIframe helper into a standalone commit, addressing the code duplication concern from the Copilot review. @yongsooim feel free to pull that commit directly — happy to close #315498 if you prefer to squash it into your branch instead.

[yongsooim]

Thanks @harshagarwalnyu for taking a look and for opening the companion PR. I folded a corrected version of that helper extraction directly into this PR in 871021f, keeping the existing getOuterIframeClient JSDoc attached to the function.