Play/Pause on the queue slot's playbar resumes Spotify instead of pausing the queued track

[LargeModGames]

Describe the bug

When the native queue is playing a queued Spotify track, the playbar shows that track, but Play/Pause does not pause it. App::toggle_playback skips every per-source arm, reaches the streaming branch, finds no item on current_playback_context, and dispatches a bare IoEvent::StartPlayback(None, None, None). Neither queue router consumes that, so it lands on the Web API as a plain resume. The queued track keeps playing and the API either errors with no active device or resumes the last Spotify context on top of it.

To Reproduce

1. Default build, signed in, nothing playing yet, so current_playback_context has no item.
2. Press z on a Spotify track to add it to the native queue.
3. Open the Queue screen and press Enter on it. The queue slot takes over and the playbar shows the queued track.
4. Click Play/Pause on the playbar, or press the play key.
5. The track keeps playing. Nothing pauses.

Expected behavior

Play/Pause should pause and resume the queued track through librespot, like the other controls on that playbar do.

Root cause

toggle_playback (src/core/app.rs) skips the per-source arms when queue_now_is_spotify() is true, then falls into the streaming branch. With current_playback_context.item == None it takes the bare-resume path and dispatches StartPlayback(None, None, None). route_spotify_queue_transport (src/infra/queue/dispatch.rs) only matches NextTrack, PreviousTrack and ForcePreviousTrack, and the relinquish arm only matches StartPlayback(Some(_), ..), so nothing intercepts it and the runtime forwards it to handle_network_event.

Two ways out: let route_spotify_queue_transport consume PausePlayback and a bare StartPlayback for the Spotify slot, or have toggle_playback call streaming_player.pause()/play() directly when queue_now_is_spotify().

Additional context

Found while reviewing #373, not caused by it. Volume has the same shape in the sub-state where is_streaming_active is false: the dispatched ChangeVolume isn't consumed by either queue router either, so it goes to the Web API instead of librespot.