fix: un-freeze the seek bar after a stream restart or state round-trip

[chrisuthe]

Summary

The progress bar could stop advancing permanently — audio kept playing while the bar sat still for the rest of the track. Found by comparing our implementation against the protocol spec and the reference implementations, not from logs.

Root cause: the anchor lifecycle was driven by PlaybackState, but only fresh progress could ever rebuild an anchor. Two real paths reached the dead state:

1. Stream restart. The SDK synthesizes state transitions the server never sent — it forces Playing on stream/start and Idle on stream/end. A format renegotiation (or a server implementing seek as end+start) emits Idle then Playing, both carrying the same carried-forward PlaybackProgress instance. Freeze() ran on Idle; nothing was fresh, so the Playing event could not re-anchor.
2. Resume from a server that signals via group/update only, which carries just playback_state/group_id/group_name — no progress to re-anchor from.

Spec basis

Validated against Sendspin/spec @ 3632c68:

• playback_state is only 'playing' | 'stopped' (README:681) — there is no paused state, so playback state cannot be the pause signal.
• playback_speed: 0 means paused (README:1448) — this is the protocol's only pause signal.
• Inside progress, track_progress/track_duration/playback_speed are all required (README:1446-1448), so a conformant server always sends the speed when it sends progress.
• Progress is mandated only on play/pause/resume/seek/speed-change (README:1445), with no periodic guarantee — so a frozen bar may never self-heal.

Changes

• Speed factor derives from playback_speed alone; the group playback state no longer overrides it.
• New TrackProgressTracker.Resume(now) re-anchors at the current displayed position with now as the anchor time and the last known non-zero speed. Anchoring at now is what prevents a jump forward by the paused duration. No-op when already advancing, when no position is known yet, or after a pending track-change reset.
• MainViewModel.OnPlaybackStateChanged: Playing → Resume(), otherwise Freeze().
• Removed the PlaybackState != Playing early return in the position timer. It was wrong in both directions: on a conformant pause the state stays playing so it did nothing, and during a synthesized Idle it discarded ticks the tracker had already judged correct. The tracker is now authoritative; genuine stops are still covered by Freeze() nulling the anchor.
• The retained playbackState parameter now emits a Debug log when speed and state disagree — useful signal for diagnosing non-conformant servers.
• Design note: docs/superpowers/specs/2026-07-20-seek-bar-freeze-design.md.

Tests

8 new cases covering both trigger paths, resume-in-place (no pause-duration jump), speed-0 anchors, and the no-op guards. Tracker suite 43/43. Full suite 140/142 — the 2 failures are the known pre-existing resampler ones, unchanged. Release build clean at the 553-warning baseline.

Four existing tests were rewritten because they encoded the bug: two asserted that a non-playing state overrides an explicit playback_speed, and depended on a PlaybackState.Paused the protocol never emits plus a playback_speed the spec makes required. They passed only because the test supplied both sides of a boundary that never behaves that way on the wire.

Manual verification

1. Pause ~20s in, wait ~30s, resume → bar holds while paused, resumes from ~20s (not ~50s, not frozen).
2. Track change from MA and from the client's own transport → resets to 0 and advances.
3. Stream restart (seek in MA, or change output device in Settings) → bar resumes from the correct position. This is the case that killed the bar for the rest of the track before this change.