chore(workplan): record the env-var binding defect in CUST-WP-0067-T03

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

workplans/CUST-WP-0067-hub-authority-target-resolution.md

@@ -206,9 +206,29 @@ authority check when there is nothing to write. That is correct — no write, no
 authority needed — but it means a live test on a clean repo proves nothing
 about the guard.
 
-**Remaining:** one deploy. Central declares no role until a `helm upgrade`
-picks up the ConfigMap, so `--confirm-primary` needs the explicit flag until
-then. CI is building `19fab26`.
+**Defect found in this task's own work (2026-08-25).** The first deploy landed
+and central still reported `unknown` while its ConfigMap correctly held
+`primary`. pydantic-settings derives the env var from the *field name*, so a
+field named `instance_role` binds `INSTANCE_ROLE` and silently ignored the
+chart's `STATE_HUB_INSTANCE_ROLE`. The value reached the pod and was discarded.
+
+That is the same failure this workplan exists to close — configuration declared
+but never reaching what it configures — reintroduced while building the guard
+against it. The verification was too weak in a way this session had already
+learned twice: `helm template` rendering the key was treated as evidence it
+bound, exactly as `Running` was nearly treated as serving and an open port as an
+MCP handshake.
+
+Fixed by renaming the fields to `state_hub_instance_role` /
+`state_hub_instance_label`, matching the existing `state_hub_report_dir`
+precedent so the env var the chart already sets is the one that binds.
+`tests/test_instance_identity.py` now asserts the **env var name itself** binds,
+which is the check that would have caught this before deploy, plus the `unknown`
+default and rejection of invalid roles.
+
+**Remaining:** one more deploy for central to declare `primary`. Until then
+`--confirm-primary` requires the explicit flag — correctly, since central
+genuinely cannot prove it is the primary.
 
 ## Give Repo Manager a real onboarding write path