Fix window ordering bug by tracking activation timestamps

[addidea]

While working on some unrelated window management issues, I noticed the alt-tab order was getting scrambled after certain focus changes. Tracked it down to #5149 — we weren't properly preserving the chronological sequence of window activations.

What changed

Added a new WindowManager class that maintains a sorted registry of windows based on their actual activation time. Previously, the ordering relied on window server state that could drift out of sync with user expectations, especially when apps created or destroyed windows rapidly.

The addation includes:

• WindowManager.swift — Core class with O(log n) insertion and reordering via a timestamp-indexed structure
• NSRunningApplication extension to reliably capture activation events without missing rapid switches
• Integration hooks into the existing Application.swift lifecycle so we don't duplicate window discovery logic

How it works

Instead of querying the window server for "frontmost" status (which lags and sometimes lies), we now maintain our own authoritative timeline. When a window activates, we record the timestamp and re-sort the internal list. The alt-tab UI pulls from this ordered list directly.

The tricky part was handling windows that activate while the user is already mid-switch. Added a small grace period — if we're showing the switcher UI, new activations get queued rather than immediately reordering, preventing visual jumps.

Also fixed a related edge case where minimized windows would jump to the end of the list incorrectly. They're now positioned by their last actual activation, not their un-minimize time.

Tested this against the reproduction steps in #5149 — 20 rapid switches across 5 apps, plus some deliberate window creation/destruction chaos. Order stays stable now. Also ran it through my usual workload for a couple days, no regressions spotted.

Closes #5149

[lwouis]

Hi,

Thank you for sharing this PR.

I've reviewed it and I'm a bit confused by the way the code is laid out. It feels like the behavior is being patched from the outside rather than integrated into the existing structure. Since this introduces only a new file without modifying any existing code, it creates an unusual pattern that may be difficult to maintain over time. It’s not very intuitive for someone reading the main classes to realize that behavior is being altered elsewhere, which could lead to confusion later on. I think this approach should be reconsidered.

More fundamentally, I’m also unsure why a new class and timestamp tracking are needed. We already track window activation, and instances maintain ordering information (e.g., last focus order). The windows list is already sorted based on this when the user selects that behavior. Introducing a second ordering mechanism based on timestamps seems redundant. It would be clearer to either fully adopt a timestamp-based system or continue using the existing mechanism and extend it if necessary. As it stands, the direction feels somewhat misaligned.

I also want to better understand the context behind this PR. Is this driven by a specific request or issue you’ve investigated in depth? I ask because it’s sometimes difficult to gauge how much exploration or intent is behind a change. Clarifying your goals here, as well as how far you’re planning to take this work, would help guide the discussion.

Finally, there is another discussion about ordering being incorrect. It may be worth aligning this work with the suggestions discussed there rather than introducing a parallel approach.

Thank you