fix(windows): fix capture area sizing on HiDPI monitors and clean up …

[ManthanNimodiya]

Addresses three Windows multi-monitor issues reported in Discord:

1. Capture area shows only half the selected region on secondary monitors
CaptureArea on Windows was passing physical pixel bounds to inner_size()/position() which expect logical (DPI-scaled) coordinates. On a 150% DPI monitor this makes the window 1.5× too large and mispositioned. Fixed to use the same post-build resize pattern already used for TargetSelectOverlay: build at 100×100, then set logical size + physical position.

2. Ghost transparent overlay appears after every recording
When recording starts, TargetSelectOverlay windows were hidden via hide_overlay() but the WindowFocusManager monitoring task was left running. Fixed to also call fm.destroy() for each overlay when recording starts, matching the behaviour of close_target_select_overlays.

3. Overlay lingers and can reappear when main window comes back
Added an explicit overlay teardown at recording end (handle_recording_end) to guarantee any previously hidden overlays are cleaned up before the main window is restored, preventing them from being re-shown by subsequent open_target_select_overlays calls.

Greptile Summary

This PR updates Windows recording overlay behavior. The main changes are:

• Target-select overlays are hidden and their focus managers are destroyed when recording starts.
• Recording end now tears down any hidden target-select overlays before restoring the main window.
• Windows capture-area windows now use post-build logical sizing and physical positioning for HiDPI monitors.

Confidence Score: 4/5

The Windows capture-area path can panic or keep the stub window when display geometry or post-build resizing fails.

• Display geometry is now unwrapped after the window is created.
• Failed resize or position calls are ignored even though they are required for correct placement.
• The overlay teardown changes match existing lifecycle behavior and did not show a concrete broken path.

apps/desktop/src-tauri/src/windows.rs

Important Files Changed

Filename	Overview
apps/desktop/src-tauri/src/recording.rs	Adds focus-manager teardown for target-select overlays at recording start and recording end.
apps/desktop/src-tauri/src/windows.rs	Changes Windows capture-area creation to use a stub window followed by logical sizing and physical positioning.

Comments Outside Diff (3)

1. apps/desktop/src-tauri/src/windows.rs, line 2254-2256 (link)

   Display Geometry Panic

   When a selected Windows monitor is unplugged, disconnected by RDP, or otherwise changes between Display::from_id(screen_id) and this resize block, these geometry calls can return None. The previous code skipped sizing when physical_bounds() was unavailable, but this path now panics and can leave the capture window at the 100x100 stub on the primary display.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: apps/desktop/src-tauri/src/windows.rs
   Line: 2254-2256
   
   Comment:
   **Display Geometry Panic**
   
   When a selected Windows monitor is unplugged, disconnected by RDP, or otherwise changes between `Display::from_id(screen_id)` and this resize block, these geometry calls can return `None`. The previous code skipped sizing when `physical_bounds()` was unavailable, but this path now panics and can leave the capture window at the 100x100 stub on the primary display.
   
   How can I resolve this? If you propose a fix, please make it concise.

2. apps/desktop/src-tauri/src/windows.rs, line 2261-2262 (link)

   Stub Window Can Persist

   The window is first created at (0, 0) with a 100x100 size, then these fallible post-build calls are the only operations that move it onto the selected monitor and resize it. If Windows or WebView rejects either call during a DPI or monitor transition, the error is discarded and recording can continue with the capture area still on the primary display or at the stub size.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: apps/desktop/src-tauri/src/windows.rs
   Line: 2261-2262
   
   Comment:
   **Stub Window Can Persist**
   
   The window is first created at `(0, 0)` with a 100x100 size, then these fallible post-build calls are the only operations that move it onto the selected monitor and resize it. If Windows or WebView rejects either call during a DPI or monitor transition, the error is discarded and recording can continue with the capture area still on the primary display or at the stub size.
   
   How can I resolve this? If you propose a fix, please make it concise.

3. apps/desktop/src-tauri/src/windows.rs, line 2266-2271 (link)

   Height Mismatch Is Accepted

   This retry only checks the physical width after applying the logical size. On portrait monitors, fractional DPI rounding, or delayed window-manager updates where only the height is wrong, the capture area is accepted with an incorrect vertical size and can clip or overextend the selected region.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: apps/desktop/src-tauri/src/windows.rs
   Line: 2266-2271
   
   Comment:
   **Height Mismatch Is Accepted**
   
   This retry only checks the physical width after applying the logical size. On portrait monitors, fractional DPI rounding, or delayed window-manager updates where only the height is wrong, the capture area is accepted with an incorrect vertical size and can clip or overextend the selected region.
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
apps/desktop/src-tauri/src/windows.rs:2254-2256
**Display Geometry Panic**

When a selected Windows monitor is unplugged, disconnected by RDP, or otherwise changes between `Display::from_id(screen_id)` and this resize block, these geometry calls can return `None`. The previous code skipped sizing when `physical_bounds()` was unavailable, but this path now panics and can leave the capture window at the 100x100 stub on the primary display.

### Issue 2 of 3
apps/desktop/src-tauri/src/windows.rs:2261-2262
**Stub Window Can Persist**

The window is first created at `(0, 0)` with a 100x100 size, then these fallible post-build calls are the only operations that move it onto the selected monitor and resize it. If Windows or WebView rejects either call during a DPI or monitor transition, the error is discarded and recording can continue with the capture area still on the primary display or at the stub size.

### Issue 3 of 3
apps/desktop/src-tauri/src/windows.rs:2266-2271
**Height Mismatch Is Accepted**

This retry only checks the physical width after applying the logical size. On portrait monitors, fractional DPI rounding, or delayed window-manager updates where only the height is wrong, the capture area is accepted with an incorrect vertical size and can clip or overextend the selected region.

_{Reviews (1): Last reviewed commit: "Merge branch 'main' into fix/windows-mul..." | Re-trigger Greptile}

Context used:

• Context used - CLAUDE.md (source)
• Context used - AGENTS.md (source)