CheckRequest: send the real board's test-mode handshake

The host waits up to 5s after CheckRequest for TestModeChange ENTER
(8C 01 0D) before anything else, and sends no requests until the
matching EXIT (8C 00 0C) arrives; vRIO jumped straight to the
CheckReply dump, so hosts logged "RIO never came back from check
request" and skipped the version exchange. Bracket the per-board
BoardOk replies with enter/exit, byte-for-byte what the real v4.2
board sends on the wire tap.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

README.md

@@ -50,11 +50,13 @@ device behavior grounded in the **real v4.2 firmware dump**
   9600 8N1), never closer. A virtual null-modem has no UART, so unpaced
   writes would land at the host in microsecond bursts no real board could
   produce; vRIO's writer thread schedules each byte against a monotonic
-  slot deadline instead, so e.g. the 45-byte CheckRequest response takes
-  the same ~47 ms it takes real hardware.
-- `CheckRequest` → one `BoardOk` CheckReply per board (the 11 boards from the
-  legacy firmware's table). `VersionRequest` → configurable version,
-  default **4.2**.
+  slot deadline instead, so e.g. the 51-byte CheckRequest response takes
+  the same ~53 ms it takes real hardware.
+- `CheckRequest` → the real board's init handshake: `TestModeChange` **enter**,
+  one `BoardOk` CheckReply per board (the 11 boards from the legacy firmware's
+  table), then `TestModeChange` **exit**. Hosts wait (≤5 s per step) on both
+  test-mode packets and send nothing while test mode is active, so the exit is
+  mandatory. `VersionRequest` → configurable version, default **4.2**.
 - `ResetRequest` re-zeroes the targeted axis (or all).
 - A NAK re-sends the last event up to **4 times**, then gives up with a
   RESTART byte — the real board's retry budget.