[RickatRITE]

Follows up on #410.

Problem

A Web API play that names tracks directly (PUT /v1/me/player/play with "uris": [...] and no context_uri) now reaches the device with the context uri spotify:webapi. #410 fixed the same request when it came with no uri at all. spotify:webapi is not a context type, so the play is refused, the API still answers 204, and nothing plays:

level=warning msg="failed resolve spotify:webapi" error="failed creating track list: failed initializing context resolver: unsupported context type: spotify:webapi"
level=warning msg="failed loading context for play command" error="failed creating track list: failed initializing context resolver: unsupported context type: spotify:webapi"

I saw this with the v0.10.5 Windows release (audio_backend: wasapi, zeroconf credentials) on 2026-11-13, for every such play over about 40 minutes; master has the same check. Spotify goes on reporting the device as playing, so a pause sent to it afterwards fails with 403 Restriction violated, and the daemon logs failed handling dealer request with no primary stream. I can't tell exactly when Spotify started sending this uri.

Fix

InferSpotifyIdTypeFromContext treats spotify:webapi (WebApiTrackListUri) like a missing uri, so the inline items decide the type, as they have since #410. Any other unrecognised uri is still refused, as 1d150cc intended. The context keeps its uri, so the state reported back to Spotify names spotify:webapi as it was given.

The second commit is a small follow-up. With metadata.context_sweep enabled, starting such a list scheduled an enumeration of spotify:webapi, which fails with unsupported context type. It is now skipped, as the list with no uri already is. It's a separate commit in case you'd rather not take it.

Tests

• TestInferSpotifyIdTypeFromContext: new cases for spotify:webapi with tracks, with episodes, with gids only, and with no items.
• TestNewContextResolverWebApiUris: such a context resolves with no spclient, so nothing is fetched.
• TestContextSweepSkipsBareTrackLists: neither list is swept.
• Each new case fails without the change it covers.
• gofmt, go vet and go test -count=1 -tags "test_unit test_integration" ./... pass on Linux, and this branch's CI passed on Ubuntu, macOS and Windows on my fork.
• On the Windows machine above, I replaced v0.10.5 with the Windows binary CI built from the first commit. The same Web API play now logs started wasapi output and loaded track (paused: false, ...), and audio plays.

Not covered

I left these alone, since I haven't seen Spotify send them:

• Inline tracks with a playlist_number_of_tracks that doesn't match still lead to a resolve of the uri, which fails. A list with no uri behaves the same.
• A transfer whose context is only spotify:webapi, with no pages, is not empty to emptyContext, so it doesn't fall back to the current track as an empty context does.
• Autoplay after such a list seeds the station with spotify:webapi as the context uri. I haven't checked whether Spotify accepts that.

🤖 Generated with Claude Code