Fix session command queue stall that detaches Now Playing (fixes #31)

[chamika]

Fixes #31

Root cause

Media3 serializes controller commands per controller: ConnectedControllersManager.flushCommandQueue() only advances when the previous callback's ListenableFuture completes. Four callbacks in DashTuneSessionCallback could return futures that never complete — onAddMediaItems, onSetMediaItems, onGetItem, and onPlaybackResumption had no timeout guards (unlike onGetChildren/onSearch, which already use an 8s withTimeoutOrNull).

Resolving a large uncached playlist chains one Jellyfin API call per track (each retried ×3 with backoff in JellyfinMediaTree.retryOnFailure), so on flaky car connectivity a single onSetMediaItems could hang effectively forever. One wedged future permanently stalls the AAOS Media Center's command queue, which explains every reported symptom:

• audio keeps playing (ExoPlayer's internal playback thread is unaffected)
• Now Playing freezes on the previous track (metadata updates never reach the controller)
• playlist switches and search are silently swallowed (queued behind the stuck command)
• only an infotainment restart recovers

Changes

• DashTuneSessionCallback: all four unguarded callbacks now complete within 8–10s. onAddMediaItems/onSetMediaItems complete exceptionally on timeout/failure — verified in media3-session 1.9.2 sources that Media3 drops the failed command and keeps the queue alive (the current playlist keeps playing). onGetItem returns the existing error-with-Retry result; onPlaybackResumption falls back to an empty restore. The onSetMediaItems body was extracted verbatim into resolveSetMediaItems() to sit under the guard.
• DashTuneMusicService: explicit Jellyfin SDK HTTP timeouts (5s connect / 7s request / 7s socket) instead of the 30s defaults, so a single call always fails before the callback guard fires.
• JellyfinMediaTree.retryOnFailure: 10s per-attempt hard cap as defense in depth for all 9 tree network paths, and rethrows CancellationException instead of swallowing it (which would have broken the outer guards).
• New test JellyfinApiTimeoutTest: pins the timeout config against a server that accepts TCP connections but never responds — passes in 7.2s, exactly the configured request timeout.

Also includes the v1.2.9(25) release commit.

Testing

• ./gradlew :automotive:assembleDebug ✅
• ./gradlew :automotive:testDebugUnitTest ✅ (including the new timeout test)
• Manual repro suggestion: start playback against a real server, then replace it with nc -lk 8096 > /dev/null (accepts connections, never responds) and switch playlists — commands should fail within ~10s with the session staying responsive, and recover without an infotainment restart once the server is back.

🤖 Generated with Claude Code