Device tracker/sensor entities freeze permanently a few seconds after creation, despite coordinator successfully fetching data every cycle with zero errors

A newly-added tracked device (a "Nut" branded BLE tag) has its `device_tracker` and `sensor` entities freeze completely within seconds of being created, and never update again — despite the device actively advertising nearby and the coordinator itself reporting healthy updates.

Evidence the coordinator/backend is fine:
- Coordinator logs `Finished fetching bermuda data in 0.001 seconds (success: True)` roughly every second at DEBUG level, with zero exceptions/errors, for the entire duration of the freeze.
- `/api/diagnostics/config_entry/` shows the device's internal `adverts` dict actively accumulating real data (`hist_rssi`, `hist_distance`, `hist_stamp`, etc.) from our ESPHome BLE proxy, with recent `last_seen` timestamps.
- Diagnostics show `create_sensor_done`, `create_tracker_done`, `create_number_done`, `create_all_done` all `true`.
- nRF Connect confirms the tag is actively broadcasting nearby, RSSI -47 to -55 dBm.

Yet:
- `device_tracker._bermuda_tracker` and `sensor._distance` never advance past their initial creation state — `last_updated`/`last_changed`/`last_reported` all frozen at the same timestamp indefinitely (monitored for several minutes at a time, well past the 10s `update_interval`).
- `sensor._distance` and `sensor._nearest_rssi` stay `unknown` forever — they never receive even a single real value before freezing.
- Searching the full HA core log (`ha core logs`) for `nut`, `exception`, `traceback` around the freeze window returns nothing at all.

## Steps to reproduce
1. Add a BLE tag (in our case, a "Nut" brand tracker) to Bermuda's `configured_devices` via the "Select Devices" options step.
2. Reload the Bermuda config entry.
3. Watch `device_tracker._bermuda_tracker` — it updates once or twice, then freezes permanently (in our latest test, it froze from the very first reading after reload).

## Steps we've tried (no effect on the freeze)
- Reloading the Bermuda config entry (multiple times)
- Removing and re-adding the device to `configured_devices`
- Uninstalling the tag's companion app and unpairing it from any nearby phone (ruling out a competing BLE connection)
- Physically factory-resetting the tag (long-press reset)
- Enabling `custom_components.bermuda` at DEBUG level and reviewing full HA core logs — no errors found anywhere, not even at DEBUG

## Device info (from diagnostics export, MAC anonymized by HA's own redaction)
- Advertised local name: `nut`
- Manufacturer data company ID: `0x0059` (Nordic Semiconductor ASA — likely just the tag's BLE chip vendor default, not necessarily meaningful)
- `address_type`: `bd_addr_random_resolvable`
- `service_uuids`: `00001803-0000-1000-8000-00805f9b34fb` (Link Loss Service)
- `service_data`: UUID `0000180a-...` (Device Information Service), payload containing the device's own MAC bytes
- MAC address has **not** rotated at all across ~2 hours of testing (ruling out address-rotation as a factor here)
- Scanner: ESPHome Bluetooth proxy (M5Stack Atom Lite), signal strong and consistent throughout (RSSI ~-47dBm)

## Additional context
We previously observed what looks like the exact same freeze pattern (entity stops updating after a handful of cycles, `create_*_done` flags all `true`, no errors anywhere) on a completely different tag (a Tile Mate, 2024 model). That device also had a separate, unrelated dealbreaker (its MAC genuinely rotates every so often, a documented Tile anti-stalking feature), so we couldn't fully isolate whether the freeze was related to MAC rotation or something else at the time. With this new tag's MAC being stable throughout, we can now confirm the freeze is **not** caused by address rotation, and seems to be a separate, reproducible issue in how the entity write-back happens after the coordinator has otherwise successfully processed the device's data.

## Environment
- Bermuda version: 0.8.7
- Home Assistant Core: 2026.9.1 (Home Assistant OS, Supervised)
- Bluetooth source: ESPHome Bluetooth proxy (M5Stack Atom Lite)