Read the rejection properly: it was a command id, not a key refusal

Makinolo's Zwift Ride write-up gives the client command format — `00`
then protobuf field 1 with the parameter, so `00 08 00` is the
information request and `00 08 82 06` is parameter 770. Which explains
what the pod has been telling us all along.

We wrote frames beginning `0xff`. The pod answered `3e 08 ff 01 10 05` —
`{1: 255, 2: 5}`. **255 is 0xff**: our own first byte, echoed back as the
command id, with a status. It was never rejecting a key exchange; it was
saying "command 255, unsupported". `0xff` is a device-to-app notification
type and we were writing it back as though it were a command.

The same write-up records that Zwift "got rid of the Bluetooth
communication encryption they were using for the Play and the Click" —
and the Click v2 is newer than the Ride. So the crypto gate this line of
work assumed may not exist at all, which fits the plain fact that the
cleartext buttons work for the first fifty seconds.

That reopens A-2 from a better angle. It calls the thing that removes the
daily unlock a **keep-alive**: a periodic message, not a credential. So
`--keepalive <secs>` sends a chosen frame on a timer for the whole run
and lets the paddle oracle answer, and `info` and `param770` are
variants — the two commands the write-up documents, in the shape it
documents them.

If a periodic `00 08 00` holds the paddles open past the cliff, the fix
is a heartbeat in the controller supervisor and no cryptography at all.

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

crates/probe/src/unlock.rs

@@ -91,7 +91,31 @@ pub fn variant(name: &str) -> Option<&'static Variant> {
     VARIANTS.iter().find(|v| v.name == name)
 }
 
+/// A command, in the form the Zwift Ride protocol write-up documents: the byte
+/// `0x00`, then protobuf field 1 carrying the parameter.
+///
+/// This is the shape we should have been writing all along. Our `0xff …` frames
+/// were being read as *command 255*, and `0x3e {1: 255, 2: 5}` was the device
+/// saying so — the command id echoed back with a status, not a rejected key.
+pub fn command(param: u64) -> Vec<u8> {
+    let mut frame = vec![0x00];
+    field_varint(&mut frame, 1, param);
+    frame
+}
+
 pub const VARIANTS: &[Variant] = &[
+    Variant {
+        name: "info",
+        why: "the documented information request, `00 08 00` — if the command channel \
+              works at all, this is what proves it",
+        build: |_, _| command(0),
+    },
+    Variant {
+        name: "param770",
+        why: "`00 08 82 06`, the other documented command; 770 is 0x0302, which is the \
+              pod's own RideOn marker read as a number",
+        build: |_, _| command(770),
+    },
     Variant {
         name: "compressed+ours",
         why: "what we have already sent twice — the control for the sweep",
@@ -242,7 +266,7 @@ fn read_varint(b: &[u8], i: &mut usize) -> Option<u64> {
 }
 
 /// The pod's key offer, as much of it as we can name.
-#[derive(Debug, Clone)]
+#[derive(Debug, Clone, Default)]
 pub struct KeyOffer {
     /// Field 1 — 33 bytes, a compressed P-256 point.
     pub public_key: Vec<u8>,