Design 02 §3.3 predicted a `Stream` variant "when the documented
progressive-streaming follow-up lands". It landed first:
`local_playback::play_plex_track` already resolves the part URL and
Range-streams it through `qbz_player::remote_stream`, keeping the
whole-file download only as the fallback for a server that refuses
Range. Stage 3 cannot route playback through the ticket while the
ticket has no way to say "stream this".
`PlexSource::playback` now calls `plex_resolve_part_url` instead of
`plex_resolve_track_media`: the ticket resolves a LOCATION, it does not
fetch a body. Dropping the old `resolve_track_media` fallback is not a
behaviour loss — both functions run the same metadata request, the same
parse and the same part-key extraction, and only then does the second
also GET the body, so every way the first can fail the second fails
identically. Carrying the url on the ticket also removes the duplicate
metadata round trip the fallback performed.
`duration_secs` comes from the queue row rather than the core's current
track: a caller may be priming a row that is not current yet, where the
core would answer about a different one.
The url embeds credentials (Plex's token, and Jellyfin's / Subsonic's
when they arrive), so `Debug` redacts the query string while keeping the
origin — telling a LAN address from a plex.tv relay is exactly what the
perf log lines exist to answer. Three tests cover the redaction and the
`play_id()` arm.
cc
vicrodh
7113ef5794