feat+fix(config): add Auto streaming mode with is_active && is_playing disambiguation - #1049

Summary

enable_streaming currently accepts Always, DaemonOnly, and Never. There is no option for the common case where the user already has a Spotify Connect device active (phone, smart speaker, TV) and does not want the terminal client to spin up a second local audio engine.

This PR adds Auto, with one important refinement discovered during local validation:

• When Auto is selected, the client queries both available_devices() and current_playback(). Web API remote-control mode is only entered when both signals agree: a Connect device reports is_active == true and the user's account currently reports is_playing == true. Any other case (no devices, devices online but idle, or a failed playback probe) falls back to the existing Always path and boots a local librespot session.

Typical use case: an Amazon Echo linked to the user's account is sitting idle in another room. Opening the terminal client on the laptop should pair audio locally, not defer to the standby Echo.

Background

The initial scope of this PR used is_active alone as the disambiguator. Local validation against a real account showed that a Connect device which is online but idle still reports is_active == true, which would leave the TUI in Web API remote-control mode with no local audio engine and surface a misleading No playback found message. Cross-referencing current_playback().is_playing rules out that case without re-introducing the original problem the user wanted to avoid (a second audio engine while a real device is playing).

The fix is intentionally narrow:

• is_active == true && is_playing == true → Web API mode (existing behaviour).
• is_active == false (no devices, or all idle) → local librespot.
• is_active == true && is_playing == false (online device, idle account) → local librespot.
• available_devices() error or current_playback() error → local librespot, with a tracing::warn! explaining which probe failed. This preserves the Always-style fallback semantics.

Changes

This PR adds only the is_active && is_playing disambiguation. The base Auto enum variant and its branches live in #1049.

• client/mod.rs::new_session() — refines the Auto branch from feat+fix(config): add Auto streaming mode with is_active && is_playing disambiguation #1049. Instead of using is_active alone, the new branch cross-references available_devices() with current_playback() and only enters Web API mode when both signals agree. Any disagreement (or probe failure) falls back to local librespot with a tracing::warn! explaining which probe failed.

Compatibility

• Default stays Always; existing users see no behaviour change.
• enable_streaming = "Auto" is now a valid value. Existing true / false, Always, DaemonOnly, and Never continue to work identically.
• No public API changes. StreamingType is a public enum and adding a variant is additive.

Validation

cargo fmt --all -- --check
cargo check --no-default-features --features rodio-backend,media-control,streaming,image,notify,fzf
cargo clippy --no-default-features --features rodio-backend,media-control,streaming,image,notify,fzf -- -D warnings

All three pass clean. Full release build also succeeds (cargo build --release --features streaming,image,notify,media-control,rodio-backend,fzf).

Repro / environment

Verified by the reporter on:

• spotify-player: aome510/spotify-player@feat/streaming-auto-mode at 9df680b, Cargo.toml version 0.24.1
• Base branch: feat/streaming-auto-mode (this PR adds the fix on top of feat+fix(config): add Auto streaming mode with is_active && is_playing disambiguation #1049 and cannot be merged until feat+fix(config): add Auto streaming mode with is_active && is_playing disambiguation #1049 lands)
• OS: Debian forky/sid (kernel 6.19.14+deb14-amd64)
• Compositor: niri (Wayland)
• Terminal: Ghostty (TERM_PROGRAM=ghostty)
• Run command: cargo build --release --features streaming,image,notify,media-control,rodio-backend,fzf then launched from a distrobox enter arch-loust Arch container
• Client ID: bundled default (NCSPOT_CLIENT_ID constant)
• Test config (from ~/.config/spotify-player/app.toml): enable_streaming = "Auto", enable_audio_visualization = true, enable_notify = true, enable_media_control = true

Local log evidence (sanitized — track names and URIs removed, identifiers kept) showing the fix correctly identifying an idle Echo and falling back to local librespot:

INFO  librespot_playback::audio_backend::rodio: Using Rodio sink with format S16 and cpal host: ALSA
INFO  librespot_playback::audio_backend::rodio: Using audio device: default
INFO  spotify_player::client: Auto streaming: no active playback detected
      (active_devices=false, playing=false); initializing a local librespot player
INFO  librespot_playback::player: Loading <track-1> with Spotify URI <spotify:track:REDACTED>
INFO  librespot_playback::player: <track-1> (165857 ms) loaded
INFO  librespot_playback::player: Loading <track-2> with Spotify URI <spotify:track:REDACTED>
INFO  librespot_playback::player: <track-2> (78342 ms) loaded

Notes

• The is_active && is_playing predicate makes Auto mode robust against standby devices that are online but not playing. Users who only want the local player regardless of Connect state can still use Always.
• If either the device query or the playback probe fails (network error, 429), the branch falls back to Always rather than failing startup. Duplicate audio is preferable to a client that won't start.
• This PR is incremental on top of feat+fix(config): add Auto streaming mode with is_active && is_playing disambiguation #1049. The earlier draft that only considered is_active lives in feat+fix(config): add Auto streaming mode with is_active && is_playing disambiguation #1049's branch; this branch stacks the is_active && is_playing refinement on top of it.