docs: drop COMPLIANCE §8 "out of scope" and broaden §7 to all 4 validators

§8 was carrying two items that neither read as "deliberately out of
scope" nor matched the framing of the section:

- Equipment Processing States — E30 §6.3 explicitly leaves concrete
  states tool-defined.  The framework ships the ControlTransitionTable
  engine and YAML loader; vendors supply IDLE/SETUP/READY/EXECUTING.
  That's a design choice, not a gap.  §3 line 94 already documents
  it.
- Serial-port wiring for SECS-I — the FSM is implemented and tested
  end-to-end over TCP; only the asio serial_port adapter is missing.
  That's deferred, not out of scope.  §1a line 64 already lists it
  with status ⬜.

So §8 is dropped, §9 renumbers to §8, and the deferred follow-up
gets its own short section in the README so customers know it's
tracked without sounding defensive.

§7 used to be titled "Interoperability with secsgem-py 0.3.0" and
mentioned only that one external implementation.  We now have four
external validators (secsgem-py + secs4java8 + tshark dissector +
libFuzzer), so the section is renamed "Interoperability with
external implementations" and broadened to cover all of them with
their actual check counts.  Stale "24 named checks" updated to the
current 31; "three consecutive clean runs" line dropped as
audit-language no longer earning its keep now that it's a CI step.

FAQ's "What's not implemented?" answer rewritten to point at the
README "Deferred follow-ups" section and COMPLIANCE §8 (new
numbering), with a brief note explaining that Equipment Processing
States are spec-by-design tool-defined.

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

FAQ.md

@@ -218,10 +218,21 @@ INTEGRATION.md §6.4.
 
 ## What's not implemented?
 
-See [COMPLIANCE.md](COMPLIANCE.md) §8 ("Explicitly out of scope")
-for the honest list.  The short version: tool-specific Equipment
-Processing States (the engine is there, vendors plug in their
-states), the serial-port driver for SECS-I (the FSM is wired
-end-to-end over TCP, the asio `serial_port` glue is a deferred
-follow-up), and GEM RTS certification (paid third-party gate, not
-a code feature).
+Every E30 Fundamental + Additional capability and every GEM 300
+standard in scope is shipped.  The two non-shipped pieces are:
+
+1. **The asio `serial_port` adapter for SECS-I** — the FSM is
+   implemented and tested end-to-end over TCP
+   ([`secsi::TcpTransport`](include/secsgem/secsi/tcp_transport.hpp));
+   the serial-port driver is a deferred follow-up (most modern GEM
+   equipment runs HSMS).  Listed under "Deferred follow-ups" in
+   [README.md](README.md).
+2. **A GEM Reference Test System (RTS) run** — paid third-party
+   certification gate, not a code feature.  See
+   [COMPLIANCE.md](COMPLIANCE.md) §8 for what "100% GEM-compliant"
+   honestly means about a codebase vs. a certified tool.
+
+Note: Equipment Processing States are tool-defined per E30 §6.3 — the
+engine ships, and vendors load their concrete states (IDLE / SETUP /
+READY / EXECUTING / …) the same way `data/control_state.yaml` is
+loaded.  That isn't a gap, it's how the spec is designed.