docs: bring the documentation up to the daemon/client era

A large gap had opened between the docs and the code: the README and
INTEGRATION guide did not mention the gRPC daemon or the Python client at
all (the entire vendor surface), ARCHITECTURE still described secs_server
as the ~1200-line canonical wiring example (it is a ~110-line thin main
over EquipmentRuntime), and test counts across six files were stale
(445/2753 -> 473/3087 core + the separate 125-assertion daemon suite).

- README: new "Integrating your tool (pick a tier)" section — Python
  client / any-language gRPC / embedded C++ — plus daemon tests and
  tools/run_interop.sh in the Testing section.
- ARCHITECTURE: layer diagram gains the vendor-surface and
  EquipmentRuntime/default_handlers tiers; stale wiring row fixed.
- INTEGRATION: three-tier chooser up front (this guide = the C++ tier).
- ch30 tour: secs_gemd + secs_gemd_tests in the binaries table.
- ch31: example alarm used a nonexistent `alcd:` field with bit 7 set
  (which the validator forbids) -> real `category:`/`name:` fields, and
  the roles: block documented.
- ch35: handler-location note now points at default_handlers.cpp's 15
  per-capability register_* functions.
- ch40: built-artifacts list + sample output counts.
- ch50: secsgem::gem runtime/default_handlers/handler_slot/name_index
  includes + new secsgem::daemon namespace section.
- PROOFS: test-count table gains the runtime/handlers/daemon row so the
  tally adds up; daemon suite noted. VERIFICATION/COMPLIANCE counts.
- interop/README: the one-command runner + the two daemon-track harnesses
  (daemon_interop, pyclient_interop).

Audited via a docs-vs-code sweep (the audit itself under-reported: it
validated counts textually; reality was 473/3087).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

interop/README.md

@@ -24,6 +24,12 @@ involve a network peer — they're either pure codec round-trips
 (KAT) or coverage-guided fuzzing.  Listed here so the full external
 proof inventory lives in one place.
 
+## One command for everything
+
+`tools/run_interop.sh` (from the repo root) runs every validation step —
+build, both unit suites, all the harnesses below, tshark, and secs4java8 —
+with a PASS/FAIL summary. `SKIP_SECS4J=1` skips the Java image build.
+
 ## Running each validator
 
 ### secsgem-py — secsgem-py active host → C++ server
@@ -34,6 +40,29 @@ docker compose run --rm interop python3 /app/interop/host_vs_cpp_server.py \
     --host server --port 5000 --session-id 0
 ```
 
+### daemon bridge — gRPC tool + secsgem-py host → secs_gemd
+
+```sh
+docker compose up -d --no-deps gemd
+docker compose run --rm --no-deps interop python3 daemon_interop.py \
+    --grpc gemd:50051 --hsms-host gemd
+```
+
+Both faces of the daemon at once: 20 checks proving gRPC SetVariables/
+FireEvent/SetAlarm reach the reference host as S6F11/S5F1 over HSMS, and
+the HCACK-4 command loop (host S2F41 → tool stream → completion event).
+
+### Python client — published secsgem-client package → secs_gemd
+
+```sh
+docker compose up -d --no-deps gemd
+docker compose run --rm --no-deps -e PYTHONPATH=/app/clients/python interop \
+    python3 pyclient_interop.py --grpc gemd:50051 --hsms-host gemd
+```
+
+13 checks driving the PUBLISHED Python API (eq.set / eq.fire / eq.alarm /
+@eq.on) against a live daemon, with secsgem-py judging the wire.
+
 ### secsgem-py — C++ host → secsgem-py equipment
 
 ```sh