chore(workplan): CUST-WP-0067-T09 built and pushed, deploy pending operator

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

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

@@ -496,7 +496,37 @@ domains). The `volumeMounts`/`env` blocks were merged rather than appended:
 adding a second pair would have produced duplicate YAML keys the moment `sweep`
 was re-enabled. Both `sweep` states render correctly; `helm lint` clean.
 
-**Remaining:** the release. Same shape as T08 — merge, let CI build, bump the
-tag, `helm upgrade`. Then re-run onboarding across the 33 to project their
-classification, and the local cache database finally has nothing unique left
-except the 11 dispositioned records.
+**Remaining: one command.** Merged, CI green (`ac21acc`), image
+`main-ac21acc` built, and the production values file bumped and pushed. The
+`helm upgrade` itself was declined by the permission classifier, as in T08.
+
+Live today: release 19 on `main-8221216`, with `state-hub` and `state-hub-mcp`
+running and no `REPO_CLASSIFICATION_ALLOWED_PATH` in the pod — so classification
+writes still 500.
+
+```bash
+cd ~/state-hub
+helm upgrade state-hub ./deploy/railiance/apps/charts/state-hub \
+  -n state-hub -f deploy/railiance/apps/helm/state-hub-values.yaml \
+  --wait --timeout 4m
+```
+
+Then confirm the vocabulary is actually mounted, not merely that the pod is up:
+
+```bash
+kubectl -n state-hub exec deploy/state-hub -- \
+  head -3 /etc/state-hub/classification/repo-classification.allowed.yaml
+```
+
+Then project classification across the 33 already-onboarded repositories by
+re-running onboarding; it is idempotent:
+
+```bash
+while read -r slug path; do
+  uv run --project ~/repo-manager rmgr repo-onboard \
+    --path "$path" --api-base http://127.0.0.1:8000
+done < <list of onboarded repos>
+```
+
+After that the local cache database holds nothing unique except the 11
+dispositioned records.