docs: customer-ready sweep + README restructure + tshark CI fix

Audit pass over the public-facing surface so a customer can read it
end-to-end without tripping on stale numbers or self-contradictions.

README + docs accuracy:
- Test counts 426 → 445, assertions 2 557 → 2 753 (verified via
  doctest run); E5 row was missing test_e5_kat (19 cases)
- Interop checks 24 → 31, COMPLIANCE.md message count 149 → 164,
  COMPLIANCE.md "291 cases / 1515 assertions" → 445 / 2 753
- README "60+ test IDs" for MES_INTEROP → actual 59
- PVD example counts: 32 SVIDs/17 CEIDs → 29/21, "~40 handlers
  in ~200 lines" → 51 in ~460, "~700 lines" → ~1,100; main.cpp
  header table-of-contents resynced with the actual 7 sections

Out-of-scope honesty (COMPLIANCE.md §8 + FAQ.md):
- Removed HSMS-GS (was both ✅ implemented in §1 and "out of scope"
  in §8; INTEGRATION.md §7 documents using it)
- Removed multi-block SECS-I (split_message/assemble_message exist
  with 4 dedicated tests)
- Added serial-port wiring as the genuine open ⬜ item — FSM is
  tested end-to-end over TCP; only the asio serial_port glue is
  deferred
- COMPLIANCE.md intro now lists E42 and notes "E37 (SS + GS)"

README restructure:
- Moved the 8-command proof table and per-standard test-coverage
  table to a new PROOFS.md (72 lines)
- README now leads with what / Quick start / Documentation map,
  then a one-paragraph "How it's proved" linking to PROOFS.md
- Updated cross-refs in FAQ.md, GLOSSARY.md, VERIFICATION.md, and
  interop/README.md to point at PROOFS.md

CI fix — tshark-dissector job:
- interop/tshark_validate.sh hardcoded /app/build/secs_server etc.
  which only works inside the docker image.  Now derives ROOT from
  the script's own location and accepts BUILD/SERVER/CLIENT/DATA
  env overrides, so CI can run it from the workspace dir
- Verified still passes in docker (69 frames, 0 malformed)

.gitignore:
- Added build-fuzz/ and build-tsan/ (were showing as untracked)

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

COMPLIANCE.md

@@ -1,12 +1,13 @@
 # SECS/GEM Compliance
 
 A per-capability accounting against the foundational SEMI standards
-**E5 (SECS-II)**, **E30 (GEM)**, **E37 (HSMS)**, **E4 (SECS-I)**, plus
-the full GEM 300 stack: **E40** (process jobs), **E94** (control jobs),
-**E87** (carriers), **E90** (substrates), **E116** (equipment
-performance tracking), **E120** (common equipment model), **E157**
-(module process tracking), **E84** (parallel I/O), **E148** (time
-synchronization), **E39** (object services), plus **E5 §13** wafer maps.
+**E5 (SECS-II)**, **E30 (GEM)**, **E37 (HSMS, SS + GS)**, **E4 (SECS-I)**,
+plus the full GEM 300 stack: **E40** (process jobs), **E42** (formatted
+process programs), **E94** (control jobs), **E87** (carriers), **E90**
+(substrates), **E116** (equipment performance tracking), **E120** (common
+equipment model), **E157** (module process tracking), **E84** (parallel
+I/O), **E148** (time synchronization), **E39** (object services), plus
+**E5 §13** wafer maps.
 
 > **Status.** Every GEM Fundamental and every GEM Additional capability
 > that E30 binds to a concrete SECS-II message set is implemented, and
@@ -227,7 +228,7 @@ Legend:
 
 ## 5. Message coverage matrix
 
-149 SECS-II messages in the catalog, spanning streams 1, 2, 3, 5, 6, 7, 9, 10, 12, 14, 16.
+164 SECS-II messages in the catalog, spanning streams 1, 2, 3, 5, 6, 7, 9, 10, 12, 14, 16.
 
 | Pair             | Direction | Status | Notes |
 |------------------|-----------|--------|-------|
@@ -345,7 +346,7 @@ walks ~20 SECS transactions end-to-end:
 23. `S1F15`/`S1F16` Request Offline.
 24. `Separate.req` → clean close on both sides.
 
-Unit tests: **291 cases / 1515 assertions pass** (`docker compose run --rm tests`).
+Unit tests: **445 cases / 2753 assertions pass** (`docker compose run --rm tests`).
 The suite includes integration tests that drive a real `hsms::Connection`
 over a loopback socket pair to verify the E37 §7.2 / §7.4 / §7.7
 edge cases — not just the happy path.
@@ -398,9 +399,8 @@ compliance claim.
 
 | Item                                  | Why it's out of scope |
 |---------------------------------------|----------------------|
-| Multi-block SECS-I transfers          | Multi-block is a **SECS-I** concept for 244-byte serial frames. HSMS allows arbitrarily large bodies (up to the codebase's 16 MiB cap), so multi-block is structurally not needed. E37-based GEM equipment does not require it. |
-| HSMS-GS (multi-session)               | Out of scope — modern HSMS-SS covers virtually all current GEM equipment. |
 | Equipment Processing States (concrete states) | E30 §6.3 says the specific states are tool-defined. We provide the engine (`ControlTransitionTable` + the YAML loader); equipment vendors load their concrete states (IDLE / SETUP / READY / EXECUTING / PAUSE / …) the same way `data/control_state.yaml` is loaded today. Spec-compliant either way. |
+| Serial-port wiring for SECS-I         | The SECS-I FSM (`secsi::Protocol`) is fully implemented and tested end-to-end over the asio TCP transport (`secsi::TcpTransport`).  The serial-port driver (asio `serial_port` wrapper around the same FSM) is a few hundred lines of straightforward wiring that hasn't been written yet — most modern GEM equipment runs HSMS.  Plug it in by mirroring `TcpTransport`. |
 
 ---