finish CUST-WP-0067-T07 and CUST-WP-0068-T01

Repo Manager now owns the State Hub access map and the registrar no longer
fails its own generated-index precondition. Close 0067; 0068 continues with
the remaining recovery tasks.

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

@@ -4,7 +4,7 @@ type: workplan
 title: "Resolve hub target ambiguity and restore repo onboarding to the authoritative hub"
 domain: infotech
 repo: the-custodian
-status: active
+status: finished
 owner: codex
 created: "2026-08-24"
 updated: "2026-08-28"
@@ -386,7 +386,7 @@ so authority depended on where a process happened to run.
 
 ```task
 id: CUST-WP-0067-T07
-status: progress
+status: done
 priority: high
 state_hub_task_id: "dbc672d5-805a-567a-b548-4e8870e4fb2f"
 ```
@@ -453,6 +453,15 @@ reference `127.0.0.1:18000`, and they must not be blanket-rewritten —
 that are historical record. Rewriting a finished workplan or a dated report
 would falsify what was true at the time.
 
+**Done (2026-08-28):** Repo Manager is the single source.
+`config/state-hub-access.yaml` holds the live endpoints; `rmgr scaffold`
+renders the table into new `AGENTS.md` files and
+`rmgr scaffold --path <repo> --refresh-hub-access` replaces the table in an
+existing file (marked block, or the unmarked workstation/railiance01 table).
+Spot check: refreshed `the-custodian` and `repo-manager`; both tables point at
+`10.43.68.154:8000` and warn against `127.0.0.1:18000` rather than instructing
+it. Non-`AGENTS.md` historical references stay untouched, as scoped above.
+
 `state-hub-railiance01` is now unblocked for removal: nothing documented still
 points at it.