Main window created but never shown on Windows 11 (0.5.8, 0.5.9) — IsWindowVisible stays false

**Describe the bug**

On Windows 11, the Buzz Desktop main window is created with valid geometry but never becomes visible. The process starts and stays responsive, WebView2 initializes, but no window ever appears on screen. Clicking the launcher again does nothing (single-instance guard swallows it).

This is a regression: an earlier version worked on the same machine. It broke after an app update and reproduces on both 0.5.8 and 0.5.9.

**Steps to reproduce**

1. Install Buzz Desktop 0.5.9 on Windows 11 (`Buzz_0.5.9_x64-setup_alpha-unsigned.exe`)
2. Launch it from the Start menu or `%LOCALAPPDATA%\Buzz\buzz-desktop.exe`
3. No window appears. `buzz-desktop.exe` is running in Task Manager with `Responding=True`
4. Click the launcher again — nothing happens

**Expected behavior**

The main window is shown on launch.

**Version and platform**

- Buzz version: 0.5.9 (also reproduced on 0.5.8)
- OS: Windows 11 Pro 26200, single display 1920x1080 @ 100% scale
- WebView2 Runtime: 151.0.4129.72

**Logs / additional context**

Enumerating top-level windows of the `buzz-desktop` process via Win32 `EnumWindows`:

```
pid=12844 visible=False rect=(234,234)-(1674,987) title='' <- main window
pid=12844 visible=True rect=(0,0)-(16,16) title='x' <- helper
pid=12844 visible=True rect=(0,0)-(16,16) title='' <- helper
```

The main window exists at 1440x753, fully inside the display bounds, but `IsWindowVisible` returns false and never flips. Only the two 16x16 single-instance helper windows are visible. `MainWindowTitle` reports `xyz.block.buzz.app-siw`.

**What I ruled out**

- **Not a crash.** Process stayed alive and `Responding=True` for over four hours.
- **Not off-screen.** `.window-state.json` contained `{"x":-8,"y":-8,"maximized":true,"visible":true,"width":1920,"height":1009}` — the normal maximized offset on a 1920x1080 primary display.
- **Not stale state.** Reproduced after renaming both `%APPDATA%\xyz.block.buzz.app\.window-state.json` and `%LOCALAPPDATA%\xyz.block.buzz.app\EBWebView` and relaunching clean. The app recreated both and behaved identically.
- **Not WebView2 missing or failing to start.** Runtime is installed, and `EBWebView` files (`Last Version`, `Local State`, `Variations`, `BrowserMetrics-*.pma`) are written within seconds of every launch.
- **Nothing logged.** No `Application Error`, `Application Hang`, or `.NET Runtime` entries in the Windows Application event log around launch time.
- **Not a one-off hang.** Reproduces on every launch, across two consecutive versions, and after a full reinstall.

**Partial workaround (does not fully help)**

Calling `ShowWindow(hwnd, SW_RESTORE)` + `ShowWindow(hwnd, SW_SHOW)` + `SetForegroundWindow(hwnd)` externally flips `IsWindowVisible` to true, but **no content renders**. That suggests the WebView is not attached to the window, rather than the window merely being hidden.

**Repro helper**

PowerShell snippet used to enumerate the windows, in case it helps triage:

```powershell
Add-Type @"
using System;using System.Text;using System.Runtime.InteropServices;
public class W {
[DllImport("user32.dll")] public static extern bool EnumWindows(EnumWindowsProc cb, IntPtr l);
public delegate bool EnumWindowsProc(IntPtr h, IntPtr l);
[DllImport("user32.dll")] public static extern uint GetWindowThreadProcessId(IntPtr h, out uint pid);
[DllImport("user32.dll")] public static extern bool IsWindowVisible(IntPtr h);
[DllImport("user32.dll")] public static extern bool GetWindowRect(IntPtr h, out RECT r);
public struct RECT { public int L,T,R,B; }
}
"@
$t = (Get-Process -Name buzz-desktop).Id
$cb = [W+EnumWindowsProc]{ param($h,$l)
$p=0; [W]::GetWindowThreadProcessId($h,[ref]$p)|Out-Null
if ($p -eq $t) {
$r=New-Object W+RECT; [W]::GetWindowRect($h,[ref]$r)|Out-Null
Write-Host ("visible={0} rect=({1},{2})-({3},{4})" -f [W]::IsWindowVisible($h),$r.L,$r.T,$r.R,$r.B)
}; return $true }
[W]::EnumWindows($cb,[IntPtr]::Zero)|Out-Null
```

**Possibly related**

#2961 also ends with a non-rendering desktop on Windows, but through a different mechanism (WebView2 host killed after ACP session process trees exhaust the commit limit). In this report no agents were running, memory was not exhausted, and the host process stayed alive — so I believe it is a distinct failure.

**Note**

The `buzz` CLI works normally against a relay on the same machine. This appears to be desktop-only.