docs: drop implementation_plan.md, rewrite README for fab deployment

implementation_plan.md was a Layer-0..6 roadmap from the project's
spec-as-data exploration phase; every layer it described is now
shipped (Layer 0 foundations through Layer 4 message catalog +
state machines).  Removed.

README rewritten for the fab-deployment audience.  Sections added:

  1. Persistence directory layout (storage rules, disk budget, DR)
  2. Security (network isolation, TLS tunnels, audit logging,
     config signing)
  3. Monitoring + observability (signals → hooks table, Prometheus
     pattern)
  4. High availability (active/standby on shared persistence)
  5. Deployment patterns (Docker / systemd / k8s)
  6. Upgrade path (YAML reload, code rollout, schema versioning)
  7. Integration with the fab stack (MES / AMHS / OHT / recipe
     engine table)
  8. Compliance + certification (fork COMPLIANCE.md per tool, run
     RTS)
  9. Testing in production (canary, synthetic transactions, shadow
     traffic)
 10. Operational runbook (incident → first check → mitigation)

Stale stats refreshed: test count went 148/794 → 384/2390;
catalog grew to 164 messages; HSMS-GS, SECS-I T3/T4, per-port E84,
E42 formatted PPs all mentioned.

COMPLIANCE.md §9 lost its stale `implementation_plan.md` reference.

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

COMPLIANCE.md

@@ -406,10 +406,9 @@ What this codebase does **not** demonstrate, and what a real
 
 1. **Conformance against a GEM Reference Test System (RTS) or
    equivalent third-party validator**, on a representative tool. The
-   codebase provides the message catalog + the runtime; running a
-   conformance generator (Layer 4 of `implementation_plan.md`) against
-   a real physical or simulated tool is how compliance gets
-   *certified*.
+   codebase provides the message catalog + the runtime; running an
+   external validator against a real physical or simulated tool is
+   how compliance gets *certified*.
 2. **Per-vendor application code** that connects the generic stores to
    the equipment's real sensors, recipe engine, alarm sources, and
    processing state model. The codebase provides the data model and