New windows go first in the bar, not last

[grub-basket]

What happens

When a new window opens on the Mac (iTerm's New Window, an app's second document window), its thumbnail lands at the right end of the bar. That's the end most likely to be off screen, and a window just opened is usually the one wanted next.

Why

• Mac: WindowCatalog.refreshWindows keeps first-seen order and appends newcomers.
• iPad: once the bar has been rearranged, StreamClient.orderedWindows lists the device's arrangement first and every window it doesn't hold after it. So a new window went to the far end whatever order the Mac sent.

The change

Two commits:

1. Mac (WindowCatalog.swift): newcomers go first, and the rest keep their first-seen order. A device that never rearranged its bar shows this order directly.
2. iPad (StreamClient.swift): on a window list from the same Mac in the same session, windows that weren't in the last list or in the arrangement are put at the start of windowOrder, in the Mac's order, and the arrangement is saved.
   • The first list of a session and a list from another Mac add nothing, since everything in them would read as new.
   • An unarranged bar is untouched.

A setting ("New windows: first / last") could follow if you'd like one. I left it out to keep this small.

Tests

• swift build -c release.
• The iOS app compiles with this change. The Mac it was built on has only Xcode 27.0, so the build was done in a scratch copy with DuoPostureReader's iOS 27.1 calls stubbed out.
• Not run on a device or a simulator.
• No pure check covers refreshWindows or the window-list handler. I'm happy to pull the ordering rule out into a checked function if you'd prefer that.

🤖 Generated with Claude Code

[Saffsanity]

From a pass over all the open pull requests (nothing is decided yet): #66 (and #72 and #73, built on it) adds windows from other Spaces and minimized windows to the catalog, which this rule would count as new and put first on every device, and its Mac viewer compiles StreamClient.swift, so the device rule would reorder the viewer's windows too. If both go ahead, a window should count as new only the first time it appears in a session, not each time it comes back into the list.

[grub-basket]

Thanks, good catch. Pushed 3430c04: a window now counts as new only the first time it's listed, and one that leaves and comes back (minimized, another Space) takes its old place.

• Shared rule: both rules are in a new pure WindowOrder (Sources/StreamProtocol), which both ends use.
• Host: WindowOrder.seen. WindowCatalog keeps windows that left in its first-seen order (capped at 1024; the ones gone longest are forgotten first, never one that's listed now).
• Device: WindowOrder.arranged. StreamClient remembers every window id this session's lists have named (seenWindowIDs, cleared at tearDown and when the Mac changes). Only ids it has never seen go first, so Sill Viewer: a Mac controlling another Mac #66's viewer gets the same behaviour.
• Tests: Tests/checks/window-order, 14 checks with 10 of 10 mutants caught, added to the README and CI's mutants matrix. run-all.sh passes.

[grub-basket]

Merged main in (b72a681), with no rebase. The only conflicts were list entries: CI's mutants matrix and the README rows (window-order next to window-restore and clipboard). run-all.sh passes, and the iOS app builds.