fix(scene): carry display zones across the driver-scoped fingerprint change

[hyperb1iss]

Held as a draft until 0.7.0 ships. It is ready for review now.

Since the August change that added the driver segment to every device fingerprint (31e0d5d51), two displays on the owner's rig have been split in two. The Ableton Push 2 and the Corsair iCUE LINK LCD each kept a display zone pointing at the device id their old fingerprint hashed to, and the daemon minted a fresh, empty zone for their new ids. The old LCD zone still carried the configured face (Pulse Temp with custom fonts), so that face silently fell off the pump screen while the scene went on listing four display zones for two displays. After this PR, the next clean discovery sweep moves those zones to the live ids, collapses each duplicate pair onto the zone that carries a face, and tells connected clients, so the LCD gets its face back without anyone touching it.

What this changes

• Legacy id derivation. The binding remap takes every present device's fingerprint, drops its driver segment to recover the pre-August spelling, and maps that id to the live one only when a saved display zone still points at it. It skips any legacy id that two present devices would produce, or that a present device still uses as its current id.
• When the sweep runs. The remap used to run only when layout ids changed. These two devices have layout ids that read identically in both formats, because the layout id strips the owner prefix, so their scene state was never carried over. The sweep now also runs when only physical ids change, and the migration journal accepts that case.
• Collisions. A new core/src/scene/display_collisions.rs collapses display zones that end up targeting the same display. A zone with layers beats an empty one. When both have layers, the zone whose newest layer was assigned most recently wins (layer ids are UUIDv7 and every face assignment mints one). Otherwise the remapped legacy zone wins. Each collapse is logged at info. Fallback references to a removed zone are redirected to the survivor.
• Client notification. Migration commits now carry their real events: ZoneChanged for each zone updated or removed, ZoneChanged for runtime default faces, and SceneLibraryChanged for each saved scene the rewrite touched, released through the commit ticket in order. Before this, binding and layout-id migrations advanced the scene revision with an empty event batch, so an open UI or TUI kept showing removed zones and failed its next write with 404 or 412.
• Device settings are left alone. The LCD's settings row is keyed by its USB serial claim, which reads exactly like its old fingerprint, so remapping settings keys would move a correct row away.

Why

Display zones are retained across disconnects on purpose, so a device that comes back finds its face waiting. These two zones could never be matched again, because nothing would ever produce their ids, so retention preserved them forever without ever applying them. Fixing the migration, rather than pruning orphans, recovers the configuration the owner actually set.

Found while rehearsing the demo film: the rehearsal listed the extra zones, and the pump screen showed no face.

Verification

• Added or updated tests
• Added or updated docs (README, AGENTS.md, relevant spec, or guide)
• just verify passes locally (Rust fmt + lint + test)
• just deny passes (required for dependency or license changes)
• just ui-test and just ui-build pass (required for crates/hypercolor-ui/)
• just sdk-lint, just sdk-check, and just sdk-build pass (required for sdk/)
• just python-verify passes (required for python/)
• just compat-check passes (required for data/drivers/vendors/*.toml)
• just docs-build passes (required for docs or README changes)
• cd docs && zola check passes (required for docs link/content changes)
• Packaging scripts were syntax-checked (required for scripts/ or packaging/)
• just e2e-build passes with the normal Servo stack (required for daemon/UI/effect integration changes)
• just e2e-build-cpu passes when validating the CPU smoke fallback
• just e2e passes against the Servo stack (required for end-to-end behavior changes; starts daemon/browser)
• Tested on real hardware, simulator, or e2e harness (describe below)

The regression test reproduces the live shape through a full discovery sweep: saved display zones pointing at the legacy hashes of a Push 2 and a serial-claimed LCD (one carrying a face), fresh empty zones for the current ids, and devices discovered under driver-scoped fingerprints. It asserts the remap, the collapse that keeps the face, the exact ordered event batch with a single revision bump, and a second sweep that changes and emits nothing. On the base this test fails, because base reconciliation plans no remap for these layouts and returns early, leaving all four zones.

Check	Result
discovery_tests, single-threaded	18 passed (rerun independently after the last commit)
daemon --lib, single-threaded	1187 passed
internal_api_surface_tests	29 passed
core scene tests, including scene_device_binding_remap_tests	pass (two html_loader_tests need generated effect files and fail without them, unrelated)
clippy -D warnings on core and daemon (--all-targets), cargo check --workspace, fmt	pass

The full just verify gate deadlocks on this machine's GPU tests in parallel, so the daemon suite ran single-threaded instead. The computed ids match the four observed on the rig. The live rig itself has not run this build: the migration needs a clean full sweep with no scan errors, so it applies on the next daemon start that sees every device.

Notes for reviewers

• Start at the legacy-id derivation in domain/device_binding.rs. An independent review checked it against every fingerprint shape in DeviceIdentifier::fingerprint (USB serial, USB and HID path fallback, SMBus, network MAC, generic bridges) and found no wrong-device mapping. It does not cover drivers whose fingerprint changed format in other ways in the same commit: Hue, Nanoleaf, and the ROLI blocksd to roli rename. None of those exposes a display today.
• Recency means "face assigned most recently", not "configured most recently": a control edit keeps its layer id, so it does not count.
• Downgrade: an older binary refuses a migration journal that holds only physical-id changes, so it matters only if a migration is interrupted and the daemon is then downgraded.
• The same August change stranded other per-device state this PR deliberately does not move, because moving it would visibly change the rig: WLED-Gledopto's attachment profile and a settings row (brightness 0.58) under its old id, and stale Nollie and PrismRGB attachment rows. The effect-id migration has the same empty-event-batch silence fixed here and is tracked separately.

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}