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>

examples/pvd_tool/README.md

@@ -3,8 +3,8 @@
 A fictional Physical Vapor Deposition tool, end-to-end.  This is what
 a real tool integrator's deployment looks like:
 
-- `equipment.yaml` — the tool's data dictionary (32 SVIDs, 5 DVIDs,
-  7 ECIDs, 17 CEIDs, 12 alarms, 3 recipes, 9 host commands)
+- `equipment.yaml` — the tool's data dictionary (29 SVIDs, 5 DVIDs,
+  7 ECIDs, 21 CEIDs, 12 alarms, 3 recipes, 9 host commands)
 - `main.cpp` — the vendor application: sensor simulator, recipe
   runner, alarm threshold monitor, EPT cycling, metrics exporter,
   Router handlers wiring it all to the wire.
@@ -21,9 +21,8 @@ customize.  They're written to be a template, not an abstract demo.
 | §3 Recipe runner              | Driving a PJ through SettingUp → Processing → ProcessComplete by walking the recipe body, with per-step CEID emission |
 | §4 Alarm threshold monitor    | Continuous threshold-based alarm logic (chamber pressure, cleaning interval) with set/clear emission |
 | §5 EPT cycling                | E116 state transitions driven by PJ state + safety alarms             |
-| §6 Metrics                    | Prometheus exporter on `:9090` with per-CEID counters and gauge updates |
-| §7 Router handlers            | Every SECS/GEM message a host might send to a PVD tool, ~40 handlers in ~200 lines |
-| §8 main()                     | Loading YAML → validating → composing → running                       |
+| §6 Router handlers            | Every SECS/GEM message a host might send to a PVD tool, 51 handlers in ~460 lines |
+| §7 main()                     | Loading YAML → validating → composing → running, including the Prometheus exporter on `:9090` (§7.3) |
 
 ## Running it
 
@@ -138,7 +137,7 @@ from `main.cpp` directly — each section is independently usable.
    defined and you'll need them all in production.
 
 That's it.  No framework, no DI container, no abstract base
-classes.  ~700 lines of vendor code on top of the library.
+classes.  ~1,100 lines of vendor code on top of the library.
 
 ## Cross-references
 

examples/pvd_tool/main.cpp

@@ -10,10 +10,10 @@
 //   §3.  Recipe runner (drives PJ FSM through Processing → Complete)
 //   §4.  Alarm threshold monitor (pressure-based)
 //   §5.  EPT cycling (Standby ↔ Productive ↔ UnscheduledDowntime)
-//   §6.  Metrics (Prometheus exporter on :9090)
-//   §7.  Router handlers (the minimum set; mostly copied from
+//   §6.  Router handlers (the minimum set; mostly copied from
 //        apps/secs_server.cpp which has the full catalogue)
-//   §8.  main() — wires everything together
+//   §7.  main() — wires everything together, including the
+//        Prometheus metrics exporter on :9090 (§7.3)
 //
 // This file is deliberately self-contained — no pvd_internal/ helper
 // headers, no factored-out "framework."  Customers should be able to