v2: real-time Now Playing cadence + robust long-title BLE writes

Decouple the two data sources that share the BLE link:
- Anthropic usage / rate-limit: still polled every 60s.
- Windows media session: read every 3s and pushed the moment the track or
  play/pause state changes, so a song change reaches the watch in seconds
  instead of at the next 60s poll. The last usage payload is cached and merged
  into each now-playing write, so the firmware always gets one complete JSON
  object and the usage screens never blank between polls.

Fix: long media titles (a 44-char Cyrillic title -> ~256 B once json escapes
each char to \uXXXX) overflowed the ATT MTU, so every write-without-response
failed with E_INVALIDARG and tripped the zombie-link break in a reconnect loop.
Switch the RX write to response=True (WinRT does a reliable long write; the RX
char already advertises WRITE and NimBLE reassembles into its 512 B buffer) and
serialize with ensure_ascii=False so Cyrillic goes as 2-byte UTF-8 instead of
6-byte escapes. Verified on hardware: stable link, writes succeed across the
60s heartbeat.

Firmware: only re-set the Now Playing labels when the track / state actually
changed, so the faster cadence does not restart the circular title-scroll
animation on every (often identical) payload.

requirements-windows.txt: add winrt-Windows.Media[.Control]. Phase 5 imports
them but they were never declared, so now-playing silently degraded to
"nothing playing" on a fresh machine.

tests: fix two stale poll_api assertions that expected an "ok" key poll_api has
not emitted since that flag moved to the caller (connect_and_run).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

daemon/README-windows.md

@@ -118,9 +118,14 @@ python daemon\claude_usage_daemon_windows.py
   payload within a few seconds of connect (warm token path). With a valid, non-expired token
   the device should leave its waiting screen and show session + weekly percentages within
   about 10 seconds of launch.
-- The daemon then re-polls every 60 seconds while connected. If the device fires a refresh
-  request (e.g., after a button press), an immediate re-poll occurs without waiting for the
-  60-second interval.
+- The daemon then re-polls the Anthropic API every 60 seconds while connected. If the device
+  fires a refresh request (e.g., after a button press), an immediate re-poll occurs without
+  waiting for the 60-second interval.
+- The **Now Playing** screen updates on a separate, faster cadence: the daemon reads the
+  Windows media session every 3 seconds and pushes an update the moment the track or
+  play/pause state changes — so the watch reflects a song change within a few seconds, not at
+  the next 60-second API poll. The cached usage data is re-sent with each of these updates, so
+  the rate-limit / token screens never blank between polls.
 - If the device disconnects or goes out of range, the daemon logs `Device disconnected` and
   re-scans automatically with exponential backoff (starting at 1 second, capped at 60 seconds).