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>

apps/secs_client.cpp

@@ -96,6 +96,12 @@ int main(int argc, char** argv) {
             }
             return gem::s6f12_event_report_ack(gem::EventReportAck::Accept);
           }
+          // S6F25: spool-data-ready notification (E30 §6.22).
+          if (msg.stream == 6 && msg.function == 25) {
+            auto n = gem::parse_s6f25(msg);
+            logfn("SPOOL READY: " + std::to_string(n.value_or(0)) + " queued messages");
+            return gem::s6f26_spool_data_ready_ack(gem::EventReportAck::Accept);
+          }
           // S5F1: alarm send from equipment.
           if (msg.stream == 5 && msg.function == 1) {
             auto a = gem::parse_s5f1(msg);