[ENHANCEMENT] Add shared Playwright provider harness for webview components

[edelauna]

Problem (one or two sentences)

The initial Playwright visual-testing proof in #515 can mount context-free components, but most meaningful webview views depend on extension state, translations, React Query, tooltips, and VS Code messaging. Without a shared browser-side wrapper, each visual test would need ad hoc setup or broad module mocks.

Context (who is affected and when)

Contributors adding screenshots for the chat home state, settings, modes, MCP, or other provider-dependent components need deterministic defaults that run inside Playwright Component Testing's browser environment. The existing Vitest utilities are designed for jsdom and cannot be reused directly because visual tests must exercise the real browser rendering path.

Desired behavior

Provide a reusable Playwright component-test wrapper that supplies the common webview providers and controlled extension state while preserving real component and VS Code toolkit rendering.

Visual tests should be able to override only the state relevant to a scenario and mount a component without reproducing application bootstrap logic.

Constraints / preferences

• Build on the Playwright CT infrastructure introduced by [ENHANCEMENT] Add Docker-backed Playwright visual smoke testing for webview-ui #515.
• Keep the wrapper browser-side; avoid importing Vite-only modules from Node-executed test files.
• Reuse production providers where practical instead of maintaining parallel implementations.
• Provide deterministic English translations and disable network retries.
• Stub acquireVsCodeApi and capture outbound messages without requiring the extension host.
• Do not turn the harness into a full VS Code end-to-end environment.
• Preserve Vitest as the primary behavioral test layer.
• Keep defaults minimal and allow per-test overrides.

Request checklist

• I searched existing issues and did not find a separate issue for a Playwright provider harness.
• This request is a follow-up to the bounded visual-testing proof in [ENHANCEMENT] Add Docker-backed Playwright visual smoke testing for webview-ui #515.

Acceptance criteria

• A shared Playwright wrapper supplies ExtensionStateContext, translations, React Query, and tooltip providers.
• Tests can override a typed subset of extension state without constructing the full context manually.
• English translations are loaded deterministically before screenshots are taken.
• React Query retries and other nondeterministic background behavior are disabled.
• VS Code API calls are captured by a stable browser-side stub.
• Provider state is recreated for each test to prevent leakage.
• At least one provider-dependent component test demonstrates the wrapper.
• The existing context-free visual smoke test continues to pass.
• Docker visual comparison, type checking, lint, and existing webview unit tests pass.

Proposed approach

• Add a browser-side PlaywrightProviders component under webview-ui/src/__test-utils__/.
• Add typed fixture options for extension-state overrides and captured VS Code messages.
• Register the wrapper through Playwright's beforeMount hook in the component-test harness.
• Initialize i18n and a fresh QueryClient for every mount.
• Add the smallest representative provider-dependent screenshot, with the chat home state considered separately if it still requires significant extraction.

Trade-offs / risks

• ExtensionStateContextType is large and can make fixtures brittle if tests require complete objects. The harness should merge overrides into a maintained minimal default.
• Importing the production extension-state provider can pull extension-host dependencies into the browser bundle. A controlled context value may be preferable if that boundary cannot remain browser-safe.
• Global browser hooks can obscure setup. Fixture options and defaults should stay explicit and documented in code.
• This enables provider-dependent screenshots but does not replace real VS Code extension-host end-to-end tests.

Depends on: #515