Fix player freeze / detach via audio-focus hardening

[chamika]

Problem

The ExoPlayer occasionally freezes and the app becomes "detached" from the media session — switching playlist/track does nothing, and the only recovery is to play media from another app (e.g. Spotify) and reopen DashTune.

Root cause

That workaround is the diagnostic tell: the session is alive and receiving commands, but playback is stuck in audio-focus suppression. Two contributors:

1. The player was built with AudioAttributes.DEFAULT, whose usage is UNKNOWN. AAOS's strict audio-focus policy grants/returns focus unreliably for an unspecified usage.
2. When a transient focus loss (nav prompt, chime, another app briefly grabbing focus) never receives the matching AUDIOFOCUS_GAIN, ExoPlayer sits with playWhenReady = true but playbackSuppressionReason = TRANSIENT_AUDIO_FOCUS_LOSS. The player looks alive and updates metadata, but produces no sound and won't advance. Playing another app forcibly reassigns focus and unsticks it.

Fix

• Explicit audio attributes: USAGE_MEDIA + AUDIO_CONTENT_TYPE_MUSIC so AAOS reliably grants/returns focus.
• Focus-recovery watchdog: on a transient focus-loss suppression, arm an 8s timer; if still stuck (playWhenReady true, same suppression reason), re-request focus by toggling playWhenReady. Safe — if another app legitimately holds focus the re-request is simply denied and we stay suppressed (no double audio); if the state was stale, playback resumes.
• Diagnostics: log onPlaybackSuppressionReasonChanged and set a Crashlytics custom key, to confirm the diagnosis from real freezes.

Verification

• ./gradlew :automotive:assembleDebug builds cleanly.
• On-device: play music, trigger interruptions (nav prompts / another audio app), and confirm playback resumes instead of freezing. If a freeze recurs, logcat / Crashlytics will show suppressionReason=1 with playWhenReady=true, and the watchdog log when it recovers.

🤖 Generated with Claude Code