fix(desktop): reveal over Windows shell apps

[SunkenInTime]

Windows shell-hosted apps such as Settings can refuse normal foreground activation. The old worker resolved T3 after the capture overlay existed, so it could select the overlay or another process window too late. Three of four recorded Settings attempts spent 976 to 1,190 ms in reveal before activation failed. Reveal failure also stopped the renderer handoff, which left the overlay hanging and prevented the capture from reaching the composer.

Current flow

1. The shortcut starts capture, subject to the existing 200 ms duplicate-trigger cooldown.
2. On Windows, T3 resolves and caches the exact main BrowserWindow by Electron window ID, process ID, title, and bounds. This begins before T3 is hidden and before any capture overlay exists.
3. T3 captures the foreground app and starts accessibility extraction when enabled.
4. The desktop process creates the snapshot overlay, flushes it through the compositor, and starts the flash.
5. T3 reveals the main window using restore, show, moveTop, Electron focus, cached UI Automation focus for shell-hosted foreground apps, and native SetForegroundWindow activation.
6. After the reveal attempt, the renderer receives the capture ID and renders the destination frame in the selected composer.
7. The renderer sends that frame back to Electron, and the overlay flies from the captured window into the composer.
8. The PNG and metadata finish persisting. The renderer attaches the image, waits for it to paint, acknowledges the capture, and removes the overlay.

The intended visible order is:

source captured -> flash -> T3 foreground -> flight into composer -> attachment remains

Windows foreground handling

The UI Automation worker now caches the real T3 element before overlays can affect discovery. The match requires T3's process, exact title, and either its window or content bounds, so Text Input Host and the capture overlay cannot replace the target.

For shell-hosted windows such as Windows Settings, reveal focuses the cached UI Automation element before native HWND activation. If a worker crashes or exceeds its one-second limit, T3 terminates it and creates a new worker for later requests.

If Windows still rejects the complete reveal attempt, T3 sends the capture event without making another reveal call. The capture can persist and attach instead of freezing or disappearing. This fallback protects the data, but Windows may still leave T3 behind in that exceptional case.

Tests

• 11 focused desktop test files covering foreground activation, worker recovery, capture ordering, reveal failure, command-palette capture, lifecycle, and accessibility behavior
• 185 tests passed
• Desktop typecheck passed
• Targeted lint and formatting checks passed

Manual Windows Settings motion verification is in progress on the Dev build.

Created with GPT-5.6 Sol in T3 Code using the Codex harness.