Restore Session + Qobuz Connect: persist full queue and exact track across both, with QConnect as priority

[vicrodh]

Split from #304 (reporter: @am4c130d). The track-level persistence fix landed in 77d54f99d ("fix(qconnect): always persist local session to preserve track-level restore") and shipped with v1.2.5. The design request around unifying Qobuz Connect and the local Restore Session is deeper and deserves its own ticket.

What the user asked for, distilled

I would like QBZ to save the track (if not the position in the track) and the complete queue to Qobuz Connect AND to the local Restore Session, so that I'm always back where I expected to be. If I then turn on Qobuz Connect, that should take priority and overwrite my local Restore Position, if they are different.

Two distinct moving parts:

1. Full queue, not just a current_track pointer, should survive an app restart — regardless of whether Qobuz Connect was enabled or not.
2. Conflict resolution: when both sources have state on next launch, Qobuz Connect wins, the local snapshot is discarded for the restore operation.

Acceptance

• Queue (array of track ids + context ref) is serialised to the local session store on every queue mutation, not just on track change
• Qobuz Connect state (remote queue, remote current track, remote position) is read at startup alongside the local snapshot
• If both present and they diverge, the QConnect snapshot is preferred and the local snapshot is updated to match
• If only local is present, behaves as today
• If only QConnect is present, behaves as today
• Persistence rule is documented in qbz-nix-docs/ so future sessions don't re-interpret it

Out of scope for this ticket

• Within-track position (time offset) — separate ticket
• History inaccuracy when QConnect is on — separate ticket

Thanks @am4c130d for the detailed report that made this one easy to break down.