Windows: Claude desktop app window intermittently gets stuck as always-on-top (WS_EX_TOPMOST)

### Summary

On Windows, the Claude desktop app's main window intermittently gets stuck with the `WS_EX_TOPMOST` ("always on top") extended window style set. Once this happens, the window stays visually on top of every other application — even after switching focus to another app or clicking another window — until the whole PC is rebooted. Simply restarting the Claude app does not always clear it (a freshly-opened window can already carry the flag).

### Environment

- OS: Windows 11 Home, build 10.0.26200
- Claude desktop app: observed on package version `Claude_2.2553.0.0_x64__pzs8sxrjxfjjc` (Microsoft Store / MSIX install), and recurred again after a later auto-update
- Not caused by a third-party "always on top" utility — confirmed PowerToys and similar tools are not installed/running on the affected machine

### What I confirmed (not just a visual impression)

Using the Win32 API directly (`GetWindowLong` with `GWL_EXSTYLE`), I verified multiple times, on different days/sessions, that the Claude app's visible top-level window has the `WS_EX_TOPMOST` (0x8) bit set even when:
- it is not the foreground window (confirmed via `GetForegroundWindow()` returning a *different* app's window while Claude's `EXSTYLE` still shows the topmost bit), and
- nothing the user did (that they were aware of) should have requested always-on-top behavior.

Forcing the bit off directly via `SetWindowPos(hwnd, HWND_NOTOPMOST, 0,0,0,0, SWP_NOMOVE|SWP_NOSIZE|SWP_NOACTIVATE)` immediately and durably fixes the symptom for that window instance (does not silently get re-asserted by the app afterward), which is strong evidence this is a stuck/leftover window style rather than an intentional, continuously-enforced feature.

This is not a one-off: it has now been observed to recur across multiple separate days on the same machine, sometimes appearing again on a freshly-launched app window (new PID) after the machine was rebooted, so it is not something that only accumulates within one long-running process session.

### Possible (unconfirmed) trigger

One occurrence's timing lined up closely with a Claude app auto-update (Windows Event Log showed the app's MSIX package/service being reinstalled a few minutes before the symptom was next observed). I can't confirm this is the actual trigger — it may be coincidental — but it's the only correlation I've been able to find so far, since the bug does not seem to depend on any specific in-app action the user remembers taking.

### Impact

The window aggressively covers other applications regardless of focus, which is disruptive when working with multiple windows/monitors. The only reliable fix a non-technical user has today is a full PC reboot.

### Workaround used to confirm/mitigate

As a stopgap on the affected machine, a small script polls for the Claude window(s) and clears `WS_EX_TOPMOST` via `SetWindowPos` whenever it's set. This reliably resolves the symptom within a few seconds each time it recurs, which further supports that the underlying issue is the app (or Electron) leaving this window style set rather than continuously re-applying it.

Happy to provide more diagnostic detail (window handles, exact timestamps, event log excerpts) if useful.

No repository file, test, or entry point is named. First confirm whether this repository owns the Windows desktop app rather than only the terminal tool, then investigate the WS_EX_TOPMOST state around launch and update events. Done means identifying a reproducible cause and preventing the window from remaining topmost without a reboot.

Written by the indexing model from the issue text.