[Bug]: Remote Windows host can disappear while smart sort repeatedly refreshes it #8272

Operating system

macOS client connected to a Windows 11 Orca server.

Orca version

v1.4.135 on both hosts.

Details

Short summary

A newly paired Windows runtime can appear in the macOS All hosts sidebar for a few seconds and then lose its host section even though the runtime remains connected and continues returning the same repositories and worktrees. When Smart ordering is active, the macOS renderer can also enter a repeated sort-order persistence/refresh cycle and consume more than one CPU core.

This report is intentionally sanitized: network addresses, usernames, hostnames, repository paths/names, runtime/device IDs, and screenshots have been omitted.

Reproduction

1. Run Orca on a macOS client and a Windows 11 server using the same release.
2. Pair the Windows server from the macOS sidebar.
3. Keep All hosts and Smart workspace ordering enabled, with at least one live terminal session.
4. Observe that the Windows host section initially appears with its workspaces, then can disappear or be regrouped under the local host.
5. Observe repeated remote catalog refreshes and sustained renderer CPU usage.

Expected

• A reachable registered host remains represented by its own workspace rows.
• Concurrent local and runtime catalog refreshes preserve rows owned by the other host.
• Persisting an unchanged Smart order does not trigger an endless refresh/persist cycle.

Actual

• The runtime stays registered and reachable; authenticated RPCs continue succeeding.
• Repeated repo.list calls return the same non-empty catalog, and worktree.list remains stable.
• The client/server WebSocket remains established.
• The Windows profile's sortOrder values are rewritten approximately every 3–5 seconds while the macOS renderer remains busy.

Root-cause evidence

Two related paths are involved:

1. In v1.4.135, fetchRepos() and fetchRuntimeEnvironmentRepos() both merge a fetched host catalog against get().repos captured before their await, then replace the full repos array. A late local fetch can therefore overwrite runtime rows that a faster runtime fetch just added. A deterministic store-level reproduction produces [remote] after the runtime fetch and [local] after the late local fetch.
2. Smart ordering persists every newly allocated sortedIds array to the owner host. The runtime rewrites each sortOrder with Date.now() and emits reposChanged; the client refreshes repos/worktrees, treats the new sortOrder as a worktree change, increments sortEpoch, recomputes sortedIds after the settle delay, and persists again.

Current main already merges fetched repo catalogs inside set(state) against the latest state.repos as part of 25ecf2eea, which structurally addresses the stale catalog overwrite. It does not currently have a regression test for the local-vs-runtime overlap, and the unchanged-order Smart persistence loop remains.

Acceptance criteria

• Add a regression test where a runtime catalog resolves before an older local catalog and both hosts remain in state.
• Make repeated persistence of the same per-host workspace order a no-op and avoid emitting another broad refresh event.
• Preserve persistence and notification when the effective order actually changes.
• Cover macOS-client/Windows-server behavior without platform-specific path assumptions.