The P1-4 remote-queue routers (clear/remove/reorder) existed and were
unit-tested but their call sites in +page.svelte were never wired, so
reorder/remove/clear kept diverging from the renderer when a Qobuz
Connect peer owns playback.
- handleClearQueue: route to clearQconnectQueueIfRemote() first when a
peer renderer is active; return before the local clearQueue() to avoid
double-mutation.
- handleRemoveFromQueue: map the local upcoming index to the renderer's
stable queue_item_id via the QConnect queue snapshot (slice past the
current track, index into the upcoming portion, corroborate by
track_id), then route to removeQconnectQueueItemsIfRemote(). Falls
through to the local invoke if the id can't be resolved unambiguously.
- handleQueueReorder: left local-only by design (DONE_WITH_CONCERNS).
The remote queue_reorder_tracks command needs the full target order of
queue_item_ids, which can't be reconstructed reliably from a local
upcoming from/to index pair (no per-row queue_item_id, ambiguous
duplicate track_ids, renderer shuffle/autoplay ordering). Documented
inline; sending wrong ids would silently corrupt the renderer queue.
Gate is qconnectPeerRendererActive (matching seek/volume/play-track
handlers), not bare transport-connected, so local playback under a
connected-but-not-peer session keeps mutating the local store.
cc