Windows natively minimized (not via komorebic minimize) remain tiled, causing wrong split ratios

komorebi version: 0.1.41 (commit 24c0ce0b) OS: Windows

Description

When a managed window is minimized via the native OS mechanism (titlebar minimize button or taskbar), instead of via komorebic minimize, it is not always un-tiled/removed from the workspace's container tree. It remains a "ghost" container that still consumes a slot in the active layout (e.g. BSP/VerticalStack), even though IsIconic reports it as minimized and it's not visibly on screen.

This causes visibly wrong split ratios for the remaining real windows - e.g. with 2 actually-visible windows plus 1 ghost, a VerticalStack layout gives the master window 50% and splits the remainder into two quarters instead of giving the two real windows 50/50.

So far this has been reproduced with UWP/ApplicationFrameHost.exe-hosted apps:

• Microsoft To Do (Todo.exe)
• Sticky Notes (Microsoft.Notes.exe)

Steps to reproduce

1. Open 2 windows in a workspace (e.g. Windows Terminal + Outlook) plus a UWP app (e.g. Microsoft To Do).
2. Minimize the UWP app using its titlebar minimize button (not alt+m / komorebic minimize).
3. Run komorebic state and inspect the focused workspace's containers - the minimized app is still listed as a container/window.
4. Observe the remaining 2 real windows split into smaller-than-expected regions instead of an even split.

Expected behavior

Minimizing a window through any mechanism (native OS or komorebic minimize) should reliably fire WindowManagerEvent::Minimize and remove the window from the workspace's tiling tree, matching the behavior already implemented in process_event.rs.

Workaround

Manually cycle focus to the ghost window and run komorebic unmanage, or write a script that cross-references komorebic state window hwnds against IsIconic to detect these ghosts.

Additional context

There's an existing comment in komorebi/src/monitor_reconciliator/mod.rs noting that "Windows may fire SystemMinimizeStart for windows on the affected monitor" during transient display events, and that OS-initiated minimizes are suppressed in that specific case - suggesting minimize event handling for certain apps/timings is already a known source of edge cases. This may be related, or a separate gap specific to UWP/ApplicationFrameHost-hosted windows never firing (or firing unreliably) the event komorebi listens for.