phase 1.6: counsel handoff turnkey + seed_consent_version.sh + strict mode live

The remaining production blocker is counsel-calendar bottleneck
(review + sign-off). Engineering can't make counsel move faster,
but it CAN reduce the round-trip overhead:

(1) docs/counsel/COUNSEL_HANDOFF_EMAIL_2026-05-05.md — copy-paste
    email body J can send to outside counsel. Subject line + body
    + tarball attachment instructions + headline asks (A/B/C/D
    in priority order) + post-signature operator runbook. The
    pre-flight checklist + post-signature workflow turn what
    would have been "I'll figure out the email" into "click send."

(2) scripts/staffing/seed_consent_version.sh — turnkey
    post-signature deployment. Takes the path to a (presumably
    counsel-signed) consent template markdown, computes SHA-256,
    atomically merges into /etc/lakehouse/consent_versions.json
    (creating the file if absent, with per-seed audit metadata
    in _meta.seeded_at[]), restarts lakehouse.service, probes
    /biometric/health post-restart. Idempotent: re-running with
    the same hash is a no-op for the versions array but still
    appends a [reseed] entry to the audit metadata.
    Verified live against the eng-staged template — strict mode
    flipped clean, /biometric/health 200 post-restart.

(3) docs/PHASE_1_6_BIPA_GATES.md §6.5 — post-signature deployment
    runbook embedded in the gates doc. Three steps: counsel signs
    + commits → seed_consent_version.sh → strict-mode probe.
    Plus a "pre-counsel demo seed" subsection documenting how to
    exercise strict mode BEFORE counsel signs (using the
    eng-staged template hash) so the deployment workflow is
    proven before the legal critical path closes.

Strict mode flipped live — verified post-restart:
- /etc/lakehouse/consent_versions.json populated with the
  eng-staged template hash:
  8b09591a8dc15f59197affac48909ce943d575eee01705b42303acf3b32f5c56
- POST /biometric/subject/WORKER-1/consent with deadbeef hash:
  HTTP 400 + error="consent_version_unknown"
- POST with the known eng-staged hash: passes version check
  (then 404 subject_not_found on a ghost candidate, proving
  the gate is hash-aware not auth-broken)

The hash currently seeded is the ENG-STAGED template
(pre-counsel-signature). When counsel returns the signed text,
operator runs `seed_consent_version.sh` again with the
counsel-signed markdown — the new hash gets appended; the demo
hash stays in for backwards-compat with any consent records
collected during the pre-counsel demo period (none, today).

Production blocker is now genuinely just counsel calendar:
1. J transmits reports/counsel/counsel_packet_2026-05-05.tar.gz
   per the handoff email
2. Counsel reviews + signs (their billable time)
3. Counsel returns signed text → operator runs seed script
4. Strict mode flips to canonical hash → cutover complete

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/PHASE_1_6_BIPA_GATES.md

@@ -256,6 +256,69 @@ of the design doc can be picked up then under a v2 consent template.
 
 ---
 
+## 6.5. Post-signature deployment runbook
+
+When counsel returns the countersigned consent template + retention
+schedule, the engineering side of "flip from permissive to strict
+mode" is one command:
+
+```bash
+# 1. Counsel commits their signature to §7 of the consent template
+#    markdown (or J commits the signed PDF + updates §7 with counsel's
+#    name + date). The markdown is the BINDING TEXT — the PDF is just
+#    a rendering of it.
+
+# 2. Hash the canonical signed text + seed the gateway allowlist.
+./scripts/staffing/seed_consent_version.sh \
+    docs/policies/consent/biometric_consent_template_v1.md \
+    --label "v1 signed YYYY-MM-DD by [counsel name]"
+
+# The script:
+#   - computes SHA-256 of the markdown (binding text)
+#   - atomically writes /etc/lakehouse/consent_versions.json with
+#     the new hash + per-seed audit metadata (timestamp, label,
+#     source path)
+#   - restarts lakehouse.service so the gateway re-reads the
+#     allowlist
+#   - probes /biometric/health for clean restart
+
+# 3. Verify strict mode is rejecting unknown hashes:
+TOKEN=$(cat /etc/lakehouse/legal_audit.token)
+curl -sS -X POST http://localhost:3100/biometric/subject/WORKER-1/consent \
+    -H "X-Lakehouse-Legal-Token: $TOKEN" \
+    -H "Content-Type: application/json" \
+    -d '{"consent_version_hash":"deadbeefdeadbeef000000000000000000000000000000000000000000000000","consent_collection_method":"electronic_signature","operator_of_record":"strict_mode_probe"}'
+# Expect: HTTP 400 + {"error":"consent_version_unknown", ...}
+```
+
+After this, the gateway is in counsel-tier strict mode:
+
+- Any consent grant POST whose `consent_version_hash` doesn't match
+  a known signed template is refused at intake
+- Operator typos (mistyped hash) become loud failures, not silent
+  bad records
+- Future template revisions (v2, v3, ...) require counsel re-sign
+  AND a new `seed_consent_version.sh` run before being accepted —
+  the v1 hash stays in the allowlist for already-collected subjects'
+  audit-trail compatibility
+
+### Pre-counsel demo seed
+
+For deployments that want to exercise strict mode BEFORE counsel
+signs, the same script works against the eng-staged template:
+
+```bash
+./scripts/staffing/seed_consent_version.sh \
+    docs/policies/consent/biometric_consent_template_v1.md \
+    --label "eng-staged demo seed (NOT counsel-signed)"
+```
+
+The hash entry should be replaced (rotate the demo hash out, add
+the counsel-signed hash) when counsel completes review. The
+allowlist's `_meta.seeded_at[]` array preserves the seed history.
+
+---
+
 ## 7. What this PRD is NOT
 
 - Not legal advice. The `⚖ COUNSEL` markers exist because the binding text needs lawyers, not engineers.