100%/E: Spool S6F25/F26 + auto-trigger on re-SELECT

Closes spooling.  S6F25 (NUM-MSG) goes into the catalog; S6F26
(ACKC6) likewise.  The server's on_selected handler now checks the
spool on entering SELECTED — if there's queued data, it auto-emits
S6F25 so the host can decide what to do (S6F23 Transmit vs Purge).

The happy-path demo never drops TCP so the auto-trigger doesn't fire
there, but the canonical re-SELECT path is wired.  Client gains a
handler for inbound S6F25 that logs the count and acks S6F26.

COMPLIANCE.md: Spooling Additional capability flips from 🟡 to ✅.

Remaining out of scope for spooling: persistent on-disk spool so
restarts don't lose queued events.  Demo + tests don't need it; real
fab equipment would.

Tests: 83 cases / 481 assertions.

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

data/messages.yaml

@@ -709,6 +709,23 @@ messages:
     builder: s6f24_request_spool_data_ack
     body: {kind: scalar, item_type: BINARY_BYTE, enum: SpoolRequestAck, param: rsda}
 
+  # S6F25 / S6F26 — Spool data ready notification (equipment-initiated;
+  # fires on re-SELECT when there's queued data).  Host acks with S6F26;
+  # then host decides whether to issue S6F23(Transmit) or S6F23(Purge).
+  - id: S6F25
+    stream: 6
+    function: 25
+    w: true
+    builder: s6f25_spool_data_ready
+    parser: parse_s6f25
+    body: {kind: scalar, item_type: U4, param: num_msg}
+
+  - id: S6F26
+    stream: 6
+    function: 26
+    builder: s6f26_spool_data_ready_ack
+    body: {kind: scalar, item_type: BINARY_BYTE, enum: EventReportAck, param: ack}
+
   # =====================================================================
   # S7 — Process programs
   # =====================================================================