fix: probe WebView2 backend with the real user data folder

[kattapug]

Problem

An installed Windows build (Inno installer, C:\Program Files\OpenStudio) shows the "Embedded browser backend unavailable" error screen for a normal (non-elevated) user, even though the WebView2 runtime is present and healthy.

Startup log:

Browser backend: webview2
Embedded browser backend supported: No
Detected WebView2 runtime version: 150.0.4078.83
VC++ Redistributable installed: Yes
Embedded browser backend is not available. Falling back to an error screen.

Root cause

On Windows, juce::WebBrowserComponent::areOptionsSupported() (JUCE 8.0.0, juce_WebBrowserComponent_windows.cpp) is not a compile-time capability check — it really constructs a WebView2 environment:

if (auto webView = WebBrowserComponent::Impl::Platform::WebView2::createWebViewHandle (options))
    return true;

createWebViewHandle() forwards options.getWinWebView2BackendOptions().getUserDataFolder() to CreateCoreWebView2EnvironmentWithOptions(). The three startup probes passed only .withBackend(...), so the folder was empty and WebView2 fell back to its default: <exe dir>\OpenStudio.exe.WebView2, i.e. inside C:\Program Files\OpenStudio. That path is not writable by a normal user, environment creation fails with E_ACCESSDENIED, and the probe reports the backend as unavailable.

The real WebBrowserComponent was already correct — it points at %APPDATA%\OpenStudio\WebView2UserData. Only the diagnostics probes were wrong, so the app blocked itself on a backend it could actually have used.

Evidence (Windows 11, WebView2 runtime 150.0.4078.83)

• Loader/runtime probed directly out-of-process: GetAvailableCoreWebView2BrowserVersionString → S_OK, 150.0.4078.83. Runtime is fine.
• Normal launch → Embedded browser backend supported: No.
• Same binary launched elevated → C:\Program Files\OpenStudio\OpenStudio.exe.WebView2 gets created, log flips to Embedded browser backend supported: Yes, frontend reaches boot-ready.
• Granting Users modify on that folder makes non-elevated launches work too — confirming the failure is purely the probe's user data folder, not the runtime.

Change

• New makeBrowserBackendProbeOptions() helper that adds WinWebView2().withUserDataFolder(getWebView2UserDataFolder()) on Windows.
• Used by all three probes: constructor diagnostics, buildStartupSelfTestReport(), buildStartupDiagnostics().
• MainComponent ctor now reuses getWebView2UserDataFolder() instead of repeating the path literal.

Notes

• Not compiled locally (no MSVC toolchain set up here) — relies on CI. Change is small and mechanical; the diagnosis itself was verified against the shipped 1.x installer as described above.
• Follow-up worth doing separately: determineStartupFailureCategory()'s webview2-backend-unusable branch still can't say why. Logging the HRESULT would have made this a one-minute diagnosis instead of a bisect, and docs/runtime-dependency-contract.md asks that branch to be actionable.

🤖 Generated with Claude Code