refactor(webview): extend the CSP to the remaining five Component Browser documents

[eFAILution]

Follow-up from #275.

Problem

#275 put 1 of the 6 webview documents in componentBrowserProvider.ts under a Content-Security-Policy — deliberately the loading spinner, as the smallest and lowest-risk surface: no scripts, no remote data. The other five are the ones a CSP would actually protect:

• getNoSourcesHtml — componentBrowserProvider.ts:311
• getErrorsHtml — componentBrowserProvider.ts:317
• getComponentBrowserHtml — componentBrowserProvider.ts:339
• getErrorHtml — componentBrowserProvider.ts:343
• getComponentDetailsHtml — componentBrowserProvider.ts:492

They emit inline <script> blocks and interpolate component names, descriptions and tag lists fetched from GitLab, including through the client-side markdown renderer. #238 is open against exactly that surface — parameter descriptions and notes rendered unescaped — and a CSP is the layer that would contain it rather than relying on every interpolation site escaping correctly.

Scope

For each document:

• extract the inline <script> into src/webview/client/. The esbuild config from refactor(webview): serve loading-view CSS from linted external file under CSP #275 already discovers that directory and emits to out/webview/client/, so no build change is needed.
• convert inline event handlers to delegated listeners. A nonce CSP blocks onclick= and friends; there are 33 inline handlers across the five.
• emit the CSP meta tag and load the script via assetUri + the nonce, as getLoadingHtml now does for its stylesheet.

Likely one PR per document rather than one for all five, given the handler rewrite each needs.

Depends on

The helper follow-ups from #275 should land first — #284 (unit-testable helper), #286 (assetUri guard) and #285 (nonce bias). These documents are the call sites that make them load-bearing.