Close COMPLIANCE.md gap: S9 error stream

Adds S9F1, F3, F5, F7, F9, F11, F13 to the message catalog and wires
the two emission paths that the Connection layer can drive without help
from the Router or the application: S9F7 on a body-decode failure and
S9F9 on a T3 transaction-timer timeout.

Catalog (data/messages.yaml -> generated messages.hpp)

  All six MHEAD-carrying messages (F1/F3/F5/F7/F9/F11) use the same
  shape — a single <B 10> body with the offending 10-byte HSMS header.
  S9F13 (conversation timeout) carries <L,2 <A MEXP> <A EDID>>.

Connection-side emissions (src/hsms/connection.cpp)

  emit_s9(function, mhead)   New private helper.  Builds a 9/function/W=0
                              data message whose body is <B 10> with the
                              MHEAD bytes, allocates a fresh sys_bytes,
                              and queues it onto the write path.  No
                              reply is tracked.

  S9F7 on body decode        handle_data wraps Message::from_body in a
                              try/catch.  Previously any decode error
                              closed the connection; now it emits S9F7
                              with the offending header and continues
                              reading.  Reply-side decode failure also
                              emits S9F7 and surfaces the new
                              Error::IllegalData to the waiting
                              ReplyHandler (rather than making the
                              caller wait out T3).

  S9F9 on T3 timeout         The send_request T3 callback rebuilds the
                              original outgoing MHEAD from
                              (device_id, expected_stream,
                              expected_function-1, sys, W=1) and emits
                              S9F9 before invoking the callback with
                              Error::Timeout (unchanged).

What's intentionally not yet wired (logged in COMPLIANCE.md)

  - S9F3 / S9F5 — "unknown stream / function".  These need to live in
    the Router's fallback path, which would require either the Router
    knowing about a Connection-shaped sender or the Connection's
    message wrapper learning which streams the Router has handlers
    for.  Deferred — today the fallback returns SxF0 only.
  - S9F11 — "Data Too Long".  Currently we close on oversized frames;
    we'd need to also build a synthetic 10-byte MHEAD substitute (the
    real header isn't yet available at the point of detection) and
    flush it through close_after_flush.

Tests + docs

  tests/test_messages.cpp  Round-trip every S9F* using a representative
                           10-byte MHEAD literal; check S9F13 carries
                           MEXP + EDID.  +2 cases / +37 assertions.

  COMPLIANCE.md            Error Messages row moved from "no S9 stream"
                           to a detailed status describing what's
                           emitted vs catalog-only.  Coverage matrix
                           expanded per-message (F1/F7/F9/F13 ✅;
                           F3/F5/F11 🟡 catalog-only).

Build/demo unaffected: 75 cases / 420 assertions pass; the happy-path
demo never trips a decode error or T3, so the S9 path isn't exercised
end-to-end (but unit tests prove the wire shape).

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

data/messages.yaml

@@ -550,6 +550,68 @@ messages:
       element: {kind: scalar, item_type: ASCII}
       name: ppids
 
+  # =====================================================================
+  # S9 — Protocol error notifications (E5).  All carry the 10-byte
+  # offending message header (MHEAD) as a single BINARY item, except
+  # S9F13 which carries <L,2 <A MEXP> <A EDID>>.  These are
+  # equipment-initiated (typically W=0) and host-side acks are not
+  # mandatory; we emit them on the wire but don't expect replies.
+  # =====================================================================
+
+  - id: S9F1
+    stream: 9
+    function: 1
+    builder: s9f1_unrecognized_device_id
+    parser: parse_s9f1
+    body: {kind: scalar, item_type: BINARY, param: mhead}
+
+  - id: S9F3
+    stream: 9
+    function: 3
+    builder: s9f3_unrecognized_stream_type
+    parser: parse_s9f3
+    body: {kind: scalar, item_type: BINARY, param: mhead}
+
+  - id: S9F5
+    stream: 9
+    function: 5
+    builder: s9f5_unrecognized_function_type
+    parser: parse_s9f5
+    body: {kind: scalar, item_type: BINARY, param: mhead}
+
+  - id: S9F7
+    stream: 9
+    function: 7
+    builder: s9f7_illegal_data
+    parser: parse_s9f7
+    body: {kind: scalar, item_type: BINARY, param: mhead}
+
+  - id: S9F9
+    stream: 9
+    function: 9
+    builder: s9f9_transaction_timer_timeout
+    parser: parse_s9f9
+    body: {kind: scalar, item_type: BINARY, param: mhead}
+
+  - id: S9F11
+    stream: 9
+    function: 11
+    builder: s9f11_data_too_long
+    parser: parse_s9f11
+    body: {kind: scalar, item_type: BINARY, param: mhead}
+
+  - id: S9F13
+    stream: 9
+    function: 13
+    builder: s9f13_conversation_timeout
+    parser: parse_s9f13
+    body:
+      kind: list
+      struct_name: ConversationTimeout
+      fields:
+        - {name: mexp, shape: {kind: scalar, item_type: ASCII}}
+        - {name: edid, shape: {kind: scalar, item_type: ASCII}}
+
   # =====================================================================
   # S10 — Terminal services
   # =====================================================================