The pod answers the Play handshake, and declines it

`--sweep` against a recovered pod, and two findings worth more than the
thing it was built to test.

**The v2 speaks the documented Play handshake.** Sent `RideOn 01 02` plus
a raw 64-byte key — §3.5's format, no protobuf envelope, the one shape we
had never tried because the offer's protobuf framing made it look
irrelevant — and the pod replied `RideOn 02 03` followed by 64 **zero**
bytes. That is the Play reply shape with the key zeroed: it understood
the question and refused to answer it. The four protobuf variants all
drew `0x3e {1: 255, 2: 5}`.

**And the stream then went to all-zero frames**, button frames included,
at their usual rate. We can put the pod into a state where it emits
nothing but zeros. It recovers by itself.

Also recorded: the stuck state is not permanent. The pod that opened
three sessions already past the cliff, with the `+` paddle bit pinned in
its hello, came back clean — `flag=0`, idle bitmask, `−` paddle
reporting. The unit is sealed and was never opened.

The sweep's attribution is not sound and the commit does not pretend
otherwise: five writes inside six seconds, every reply in one burst at
+11.37 s. `--variant <name>` now sends exactly one frame per connection,
which is the only way to learn which one does what. Zero frames are
counted and named rather than scrolling past as `other`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

REQUIREMENTS.md

@@ -265,6 +265,29 @@ the daily unlock is needed on this path are both answered: it is, and this is th
 > two fields the Play description has no room for. Implementing Makinolo's spec verbatim
 > would be implementing a different device's protocol.
 
+> **The v2 answers the Play handshake — 2026-08-27.** Sent `RideOn 01 02` plus a raw
+> 64-byte key (the §3.5 format, no protobuf envelope), the pod replied
+> `52 69 64 65 4f 6e 02 03` followed by **64 zero bytes** — the Play reply shape, with the
+> key zeroed. The four protobuf-shaped variants all drew `0x3e {1: 255, 2: 5}` instead. So
+> the device understands the documented handshake and declines to complete it, which is a
+> refusal rather than a misunderstanding.
+>
+> Immediately afterwards the notification stream went to **all-zero frames** — including the
+> 7-byte button frames, at their usual ~10 Hz. Whether that is the pod encrypting against a
+> key it never agreed, or a firmware path nobody meant to reach, is unknown. It is
+> recoverable: the pod came back on its own by the next session.
+>
+> **Attribution is not yet sound.** All five variants went out inside six seconds and every
+> reply arrived in one burst at +11.37 s, so which write triggered the zeros is not
+> established. `probe unlock --variant <name>` sends exactly one per connection, which is
+> how that gets settled.
+
+> **The stuck state is not permanent.** A pod that had opened three consecutive sessions
+> already past the cliff — `flag=1` from the first status frame, the escalated 60-byte
+> offer, and a hello bitmask of `ffc3ffff1f` with the `+` paddle bit pinned — came back
+> clean: `flag=0`, idle bitmask, `−` paddle reporting normally. No battery pull; the unit is
+> sealed and was never opened.
+
 > **The missing half.** Every frame above is device → app. Nothing in any capture shows what
 > a *working* client writes back, and that is precisely what a responder has to send. It
 > cannot be inferred from these five frames. Getting it means capturing both directions of a