IoEvent::Repeat from a plugin changes Spotify's repeat while internet radio plays

[LargeModGames]

Describe the bug

A plugin can dispatch IoEvent::Repeat. The decoded routers intercept it through set_decoded_repeat_from_state, which returns false for internet radio because radio has no queue to repeat. False means "not handled", so the runtime forwards the event to the Spotify network handler and repeat changes on your real Spotify device while you are listening to radio.

To Reproduce

1. Build with --features all-sources.
2. Play an internet radio station.
3. From a plugin, call the scripting API that dispatches IoEvent::Repeat (src/infra/scripting/api.rs:453).
4. Open the Spotify client. Repeat changed there, on a track you are not playing.

Expected behavior

The request should be rejected while a source that cannot honour repeat owns playback, the same way the keyboard and MPRIS paths do after #373.

Root cause

The IoEvent::Repeat arm in route_local_event (src/infra/local/dispatch.rs:131) and its Subsonic and YouTube twins return whatever set_decoded_repeat_from_state gives back, and radio has no router arm for it at all. So for radio nothing consumes the event and it reaches handle_network_event.

Additional context

Found while reviewing #373. Narrow, since the keyboard and MPRIS paths are both guarded now and a plugin is the only remaining way in. Worth fixing anyway so the "a source that has no repeat does not touch Spotify's repeat" rule holds on every path rather than most of them.

[LargeModGames]

#390 is merged (cca1d51), which fixes the internet-radio half of this. Keeping the issue open, because the root-cause section above names two paths and only one is now closed.

What still leaks

A plugin's IoEvent::Repeat still reaches the user's real Spotify device whenever the native queue slot owns playback. This one does not need the internet-radio feature, so unlike the radio case it is reachable in a plain default build.

Tracing a plugin set_repeat while queue_owns_playback() is true:

1. route_queue_event (src/infra/queue/dispatch.rs:42) has no Repeat arm. route_spotify_queue_transport falls through on _ => None, and the event is not a StartPlayback, so the router returns false.
2. The Local / Subsonic / YouTube arms call set_decoded_repeat_from_state, which gates on active_queueable_decoded_source (src/core/app.rs:5048). That helper returns false as soon as queue_owns_playback() is true, by design, so all three decline.
3. The new radio arm added in fix: IoEvent::Repeat from a plugin changes Spotify's repeat while internet ra... #390 declines too: the queue slot suspends the radio session, so radio_playback is None.
4. Nothing consumed it, so it reaches handle_network_event and then Network::repeat, which calls player.set_repeat(...) on a streaming build or PUT me/player/repeat otherwise. The user's real device changes repeat mode with nothing on screen to show for it.

Why this is clearly wrong rather than a judgement call

Both of the other entry points already guard exactly this case:

• Keyboard, App::repeat: if self.active_decoded_source() || self.queue_owns_playback() { ... } sets "Repeat does not apply to this source" and returns (src/core/app.rs:6591).
• MPRIS: if app_lock.queue_owns_playback() rejects SetLoopStatus outright and pushes a corrective LoopStatusEvent::None (src/runtime.rs:2232).

So the plugin path is the only one of the three that still falls through.

Suggested fix

Add a Repeat arm to route_queue_event gated on queue_owns_playback(). That router is compiled unconditionally and runs first in the pump, so it covers the Spotify queue slot and the decoded queue slot in one place, without touching the three per-source dispatchers. Worth a status message rather than a silent swallow, to match what the keyboard path tells the user.

Test coverage

Currently none for either half. The positive assertion added in #390 lives in live_dispatch_play_and_teardown, which is #[ignore]d and needs the live SomaFM stream plus a real audio output device, so CI never exercises the behavior. The queue-slot case is much easier: it needs only queue_now set, no audio device, so it runs in all three CI legs. Worth adding alongside the fix.