[marliechorgan]

This goes into Saffsanity#173's branch (addhumal:desktop-displays), so it can land as part of Saffsanity#173 or be picked out of it. I tested on a MacBook Pro with three displays: its built-in screen (main) under two identical BenQ MA270U monitors.

What breaks on Saffsanity#173 as it stands

A pick that lands mid-switch is dropped, but the host still says it was made. pickDesktop moves catalog.display at once (WindowCatalog.swift:99). A pick that arrives during a switch is queued as .desktop (StreamCoordinator.swift:885), and select's defer then drops it because pick != active is false (1237). The stream stays on the old display. Meanwhile the window list (2339), currentSourceRect (1067) and pointerGeometry (1110) all read catalog.display, so the device is told it has the new display, and input and the pointer map onto it. Taps land on a screen the device isn't showing, until the next restart jumps the stream there on its own.

Reproduced on that Mac with the test client: start the Desktop on display 4, pick 2, then pick 1 50 ms later.

	host streamed (its Streaming … at lines)	device told
Saffsanity#173	3840×2160, 3840×2160 (two BenQ pipelines, never the built-in screen)	desktopDisplay=1 (the built-in screen)
with this	3840×2160, 3840×2160, 3024×1964 (the built-in screen)	desktopDisplay=2 while 2 streamed, then 1

It came out the same in 4 of 4 runs of each build.

The numbers follow display IDs, not positions. realDisplays sorts by main, then displayID (WindowCatalog.swift:278). On that Mac the right-hand BenQ, which macOS names "BenQ MA270U (2)", is ID 2, so it becomes Desktop 2. The left-hand one, "(1)", is ID 4, so it becomes Desktop 3. Tapping steps right, then left. The host's list read displays=[1, 2, 4]; with this change it reads [1, 4, 2].

The change

• The coordinator keeps desktopStreamDisplay, the display the running Desktop pipeline captures. Input, the pointer and the list's desktopDisplay follow that display, never a pick that is still on its way. Its frame comes from the catalog's display first, then realDisplays, so the Desktop still takes input once Host: virtual Desktop display fallback for headless Macs (#61) Saffsanity/sill#200 lets it stream Sill's virtual display on a Mac with no other display.
• Select's defer treats "the Desktop, but the catalog has moved to another display" as a pick it still owes, so a late pick is honoured rather than dropped.
• DesktopDisplays.comesBefore puts the main display first, then the rest left to right (top to bottom where two start at the same x), which is the arrangement System Settings › Displays shows. It takes plain x/y, so StreamProtocol stays free of CoreGraphics.
• sillclient.py --pick=desktop:ID@T sends a DesktopPick, and the window list line prints displays and desktopDisplay, so this can be checked without a device.

What this deliberately leaves alone: the iOS side of Saffsanity#173, the virtual display as a Desktop target (Noah's decision on Saffsanity#91 names it, and Saffsanity#173 leaves it out), and preferMainDisplay. That property is now written but never read, and its comment ("the default path keeps displays.first") no longer holds. It belongs to Saffsanity#173's own cleanup.

How it was tested

• Tests/checks/run-all.sh with Desktop: cycle through the Mac's displays with the Desktop button (#91) Saffsanity/sill#173 and this merged onto current main: 46 of 46 checks pass.

• The two new compatibility cases use the real layout above ([1, 4, 2]) plus a stacked pair. Under Desktop: cycle through the Mac's displays with the Desktop button (#91) Saffsanity/sill#173's ID order the first reads [1, 2, 4] and fails. Both new mutants are caught (29 of 29).

• SillHostCore type-checks, and the host was built and run against the three real displays for the repro above, with this exact command:

  SILL_TEST_LOOPBACK=1 SILL_TEST_NO_ROUTER=1 .build/release/SillHost &
  python3 Scripts/sillclient.py PORT 10 desktop:4 --pick=desktop:2@4 --pick=desktop:1@4.05
  

  One caveat about how I ran it: there was no Xcode 27 on that Mac, so I built the CLI host with swiftc directly, and in that local build only I set advertise: false so it would listen on 127.0.0.1 alone. That edit is not in this PR. A stock SillHost advertises a plain door, so run the repro on a network you trust, and use your own display IDs from the displays= line.

Not exercised: the iOS app with this change (the button's labels are covered by the pure check only), and input actually landing on a real host, since sillclient sends input only to a --synthetic host. The input claim rests on currentSourceRect reading the same display as the list's desktopDisplay, which the repro shows was wrong.