Bluetooth play button can take several seconds to resume when the app's been backgrounded

### Description

Audio resumption takes multiple seconds on a phone whose screen has been off for a few minutes, when triggered via bluetooth headphones. Turning the screen on during this delay resumes playback immediately.

Looks like this caused by routing the KEYCODE_MEDIA_PLAY signal through the same path as the generic play/pause toggle signals (change added in #3297), which hits MediaEventQueue's 600ms wait. However, once the app is backgrounded long enough, the wait can last much longer than 600ms.

```
# press 1 - resolves normally
10:06:30.046 Sending KeyEvent ACTION_DOWN keyCode=KEYCODE_MEDIA_PLAY
10:06:30.064 Media button event: single-tap wait starting
10:06:30.669 Media button event: single-tap wait resolved <- 605ms
10:06:30.720 MediaFocusControl: requestAudioFocus()
10:06:30.746 playbackState=PLAYING

# press 2 - same conditions, ~10s later
10:06:40.349 Sending KeyEvent ACTION_DOWN keyCode=KEYCODE_MEDIA_PLAY
10:06:40.362 Media button event: single-tap wait starting
10:06:42.342 Media button event: single-tap wait resolved <- 1980ms
10:06:42.359 MediaFocusControl: requestAudioFocus()
10:06:42.374 playbackState=PLAYING
```

I'm not sure how to resolve this, since KEYCODE_MEDIA_PLAY should not need to go through the disambiguation (it is already an explicit signal), but #3297 reported this signal can be erroneously sent by some headphones instead of play/pause or an explicit pause.

### Step-by-step reproduction instructions

1. Start playback with Bluetooth headphones connected, then pause it.
2. Turn the screen off and leave the phone alone for a few minutes.
3. Press play on the headphones.
4. Audio will resume after several seconds.
5. Repeat the process and the delay can grow.
6. Turning on the screen in the middle of a delay resumes playback immediately.

### Screenshots or screen recording

_No response_

### Did you search for existing bug reports?

- [x] I have searched for existing bug reports.

### Device, Operating system, and Pocket Casts app version

Google Pixel 9 Pro, Android 16, Pocket Casts 8.16 (9441)

Start by tracing KEYCODE_MEDIA_PLAY from the media-button handling path through MediaEventQueue, focusing on the routing change introduced in #3297 and the 600ms single-tap wait. Reproduce the backgrounded-device sequence from the issue and verify that explicit play resumes promptly while headphone play/pause behavior remains supported.

Written by the indexing model from the issue text.