Fix Battery Guard BM6 empty realtime replies

[travel-and-cache]

Summary

• recognize and ignore the exact empty BM6 realtime sentinel emitted by Battery Guard devices
• retry affected devices with write-before-notify ordering
• preserve the upstream notify-before-write behavior for all other BM6/BM2 variants

Why

Battery Guard devices can answer the normal notify-before-write flow with an empty d15507ff... realtime frame and subsequently expose 0 V / 0% samples. The fallback is activated only after that exact sentinel because BM6 is a shared decoder used by other device variants.

Tests

• sentinel rejection and retry behavior covered by unit tests
• normal and unknown non-empty status variants retain the upstream request order
• verified live by the reporter on two Battery Guard devices

Fixes #410

[fl4p]

Merged, with a follow-up in a999a5b that makes the fallback recoverable. The sentinel detection and the ordering switch are yours, unchanged — what I changed is the state around them:

• _empty_realtime was set by any notification, including one arriving with no request pending. connect() subscribes before the first write, so one stray sentinel pinned a working BM6 onto the write-before-notify path until a restart. It's now cleared at the start of every realtime request and on connect.
• The switch was one-way. If the fallback ordering also stops answering, every poll re-entered it and timed out at 8 s forever. A timeout there now clears the preference, so the next poll tries the default ordering again.
• _q_write_before_notify did stop_notify → write → start_notify with no try/finally; a raising write left FFE4/FFF4 unsubscribed for the rest of the connection.
• On the sentinel, _q cancelled the response waiter immediately and dropped a real frame arriving tens of ms later. It now waits EMPTY_REALTIME_GRACE (0.5 s) before falling back.

Your two state-machine tests still pass as written; three more cover the stray sentinel, the revert, and the failed write. Ships in 2.21.