Media directives from per-session endpoints (deviceType A2825NDLA7WDZV) are dropped, leaving media_player frozen on a stale track

## What happens

`media_player` entities freeze on a stale track while the http2 push is healthy and connected. The card keeps extrapolating position past the end of the track (08:23 elapsed on a 05:29 track). Anything that reads `media_player` state to detect playback, in my case an automation that powers on an amp zone when a source starts playing, never fires.

It looks intermittent, which cost me a day of chasing the wrong things. It is not intermittent, it depends on which serial Amazon attributes the directive to.

## Why

Some playback is reported under a per-session endpoint rather than the Echo:

* `deviceType` is `A2825NDLA7WDZV`
* `deviceSerialNumber` is a 32 character serial that rotates per session (I have seen `C...8C9` and `4...07A` on the same speaker)
* `mediaReferenceId` is `EMP_` prefixed

`http2_handler` dispatches a media update only when the serial is in `existing_serials`. These serials never are, so the directive is dropped with no log line and no `else` branch. When Amazon sends the same information under the real Echo serial the entity updates instantly.

Over one afternoon on one account: 45 dropped media directives, all under two rotating session serials.

The payload carries nothing that identifies the target speaker, so this cannot be mapped locally from the directive. `_existing_serials` already absorbs each device's `appDeviceList` serials, which looks like the intended hook, but Amazon is not listing these session ids there.

## Proposed fix

On an unattributable media directive, ask instead of guessing: refresh the account's media players so state comes from `np/player`, debounced to at most once every few seconds. That restores correct state without inventing a mapping, and `update_entity` already returns the current track instantly on these frozen entities.

Firing an event on the dropped directive would also help, both for diagnosis and so external automation can react.

If there is an API that resolves an `EMP_` session to a device, that is the better fix and I did not find it.

## Evidence

Dropped, entity stayed frozen on the previous track:

```
PUSH_AUDIO_PLAYER_STATE : {'dopplerId': {'deviceSerialNumber': '4****************************07A',
'deviceType': 'A2825NDLA7WDZV'}, 'audioPlayerState': 'INTERRUPTED', 'quality': None,
'error': False, 'errorMessage': None,
'mediaReferenceId': 'EMP_134973C9-8E82-428C-AB00-64F03C6F142D:asin://B00O6K8HC8/',
'destinationUserId': 'A**********TPA'}
```

Handled, same speaker, arrived under its real serial and updated within a second:

```
player_state event_serial: G090L911841703WS (16 char Echo serial, in existing_serials)
```

Serial formats on this account, for telling them apart: physical Echos are 16 character `G...`, groups are lowercase 32 character hex, and these session endpoints are mixed case 32 character with `deviceType A2825NDLA7WDZV`.

One `homeassistant.update_entity` on a frozen entity returns the current track immediately, so polling works throughout and only the push attribution is affected.

## Environment

* Home Assistant 2026.3.3, Docker
* alexa_media_player 5.15.7 (HACS)
* alexapy 1.29.25
* http2 push connected, `HTTP2push successfully connected`, directives flowing
* 29 Alexa devices on the account, 5 of them Echo Dots used as sources