Native streaming device not auto-selected on startup — 404 NO_ACTIVE_DEVICE on first play, device_id stays null permanently

[cobalteclipse-dev]

Describe the bug
On every fresh launch with device_id: null in client.yml and enable_streaming: true,
spotatui attempts to auto-select the native streaming device via AutoSelectStreamingDevice.
This polls the Spotify Web API twice with 200ms gaps (400ms total). Spotify's servers
have not registered the Spirc device in that window, so the device is not found,
set_device_id is never called, and client.yml stays device_id: null permanently.
On the next launch the same race repeats. Any attempt to play a track before manually
pressing d and selecting the device results in a 404 NO_ACTIVE_DEVICE error.

To Reproduce

1. Ensure device_id: null in ~/.config/spotatui/client.yml and enable_streaming: true
2. Launch spotatui
3. Immediately try to play any track (without pressing d first)
4. See error: Spotify API 404 Not Found — Player command failed: No active device found (NO_ACTIVE_DEVICE)

Expected behavior
Spotatui should either poll for longer / with more retries on startup, or retry device
registration in the background after the initial window, so that the native streaming
device is reliably activated before the user tries to play a track.

Screenshots

┌Error──────────────────────────────────────────────────────────────────────────┐
│Api response: Spotify API 404 Not Found failed: { "error" : { │
│ "status" : 404, "message" : "Player command failed: No active device found",│
│ "reason" : "NO_ACTIVE_DEVICE" }} │
└───────────────────────────────────────────────────────────────────────────────┘

Desktop:

• OS: Linux Mint 22.1 (Xia)
• Terminal: gnome-terminal
• Version: 0.38.6

Additional context
The startup poll in src/network.rs only retries twice with 200ms between attempts.
Spotify Connect device registration typically takes several seconds after Spirc
initialises.

The two bugs compound: user gets 404 → told to press d → selects device → gets stuck
(Esc doesn't work, see related issue) → force-quits with Ctrl+C → session broken →
404 again on relaunch. Looks like a complete failure but is two separate fixable issues.

Proposed fix / workaround that resolved it
The downloaded binary also had a separate issue: Cache::new in
src/infra/player/streaming.rs passes None for the system cache path, so librespot
generates a new random device UUID on every launch regardless of the get_or_create_device_id
logic. Building from source (which already contains get_or_create_device_id) and applying
this one-line fix resolved the random UUID problem:

# In src/infra/player/streaming.rs:  
# Change:  
Cache::new(cache_path.clone(), None, audio_cache_path, None)  
# To:  
Cache::new(cache_path.clone(), cache_path.clone(), audio_cache_path, None)  

Build steps (Linux):

sudo apt-get install -y pkg-config libssl-dev libxcb1-dev libxcb-render0-dev \  
  libxcb-shape0-dev libxcb-xfixes0-dev libpipewire-0.3-dev libspa-0.2-dev libasound2-dev  
git clone https://github.com/LargeModGames/spotatui.git && cd spotatui  
sed -i 's/Cache::new(cache_path.clone(), None, audio_cache_path/Cache::new(cache_path.clone(), cache_path.clone(), audio_cache_path/' src/infra/player/streaming.rs  
cargo build --release --no-default-features --features telemetry,streaming,audio-viz-cpal,mpris,discord-rpc  
cp target/release/spotatui ~/.local/bin/spotatui  

After this, ~/.config/spotatui/streaming_cache/device_id is written on first launch
and reused on every subsequent launch — stable UUID, no d press needed.

The 400ms startup poll window is a separate remaining issue that still needs fixing
in the source regardless of the UUID fix.