docs(RMGR-WP-0005): registrar fix is gated on the railiance01 remote sweep

The registrar fix is one env var, not host provisioning: the state-hub
deployment has STATEHUB_REGISTRAR unset, and that pod is the real automated
instance -- it mounts /home/tegwick rw and /home/tegwick/.ssh for push.

But setting it now would be harmful. railiance01 has 70 repos still on
gitea-remote (92.205.130.254) against 7 on forgejo-remote (92.205.62.239),
while the workstation is 126/0 on forgejo. The pod would mint identifiers
into checkouts tracking the superseded server and push them there.

Records the required order -- reconcile railiance01's remotes first, then
enable the registrar -- and that the sweep pod is currently operating against
those stale checkouts.

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

workplans/RMGR-WP-0005-registrar-consolidation-deterministic-ids.md

@@ -75,6 +75,73 @@ removes the need for the trade.
 this instance is not the registrar. Read/project checks are unchanged.
 Cost documented in `docs/repository-standards_v0.1.md`.
 
+**The registrar was never stood up (found 2026-08-21).** T01 shipped the guard —
+non-registrar instances correctly refuse to mint — but no instance satisfies the
+registrar condition, so nothing drains the queue. Twelve registrar-sync requests
+had accumulated from `evidence-binder`, `kaizen-agentic`, `glas-harness` and
+`agentic-resources` before anyone noticed.
+
+Surveyed on `railiance01`, the designated production registrar:
+
+| Prerequisite | State |
+| --- | --- |
+| Registrar signal | **fails** — hostname is `239.62.205.92.host.secureserver.net`, so the `railiance*` prefix heuristic never matches, and `STATEHUB_REGISTRAR` is unset |
+| `repo-manager` clone | was absent; cloned 2026-08-21, `rmgr` installed into `~/.venvs/registrar` |
+| `statehub` CLI | **not installable** — `pip install ~/state-hub` fails `ResolutionImpossible`; `hub-core` installs, the conflict is elsewhere |
+| Checkout ownership | **999 files under `~/state-hub` owned by root**, because the `state-hub` pod bind-mounts `/home/tegwick` as a hostPath and runs as root. Blocks `git pull` and editable installs |
+| Checkout lineage | **points at `gitea-remote`, not `forgejo-remote`** — the host was never swept by `forgejo-tier3-remote-url-sweep-playbook`. Its `evidence-binder` tracks a different lineage and cannot see `EBIND-WP-0002` at all |
+
+The hostname heuristic is the cheapest fix and the most misleading defect: it
+reads as though a registrar exists whenever a host is named `railiance*`, but the
+production host is not. Prefer the explicit `STATEHUB_REGISTRAR` signal and treat
+the hostname fallback as unreliable, or drop it.
+
+Two consequences beyond this task:
+
+- **Security.** The `state-hub` pod mounts `/home/tegwick` **and
+  `/home/tegwick/.ssh`** as hostPath volumes. A workload with the operator's
+  private keys is a larger exposure than the registrar problem it surfaced.
+- **The remote sweep is incomplete, and this gates the registrar fix.** Counted
+  2026-08-21:
+
+  | Host | `forgejo-remote` | `gitea-remote` |
+  | --- | --- | --- |
+  | workstation | 126 | 0 |
+  | `railiance01` | 7 | **70** |
+
+  The two aliases are different servers — `forgejo-remote` is `92.205.62.239`
+  (railiance01), `gitea-remote` is `92.205.130.254` (coulombcore) — and both are
+  live. The workstation finished migrating; `railiance01` did not.
+  `forgejo-tier3-remote-url-sweep-playbook` still reads "Gitea remains canonical",
+  which was true when written on 2026-07-04 and is now stale guidance.
+
+### Why the registrar cannot simply be switched on
+
+The fix looked like one environment variable: the `state-hub` **deployment** has
+`STATEHUB_REGISTRAR` unset, and that pod is the real automated instance — it
+mounts `/home/tegwick` read-write, mounts `/home/tegwick/.ssh` at `/root/.ssh`
+for push, and carries `STATE_HUB_SWEEP_HOSTNAME`. Host-level provisioning was the
+wrong target.
+
+**Setting it today would be actively harmful.** The pod would begin minting
+identifiers into 70 checkouts that track the superseded server and pushing them
+there — writing hub primary keys into a lineage nothing reads, and re-animating
+`gitea-remote` as a write target.
+
+Required order:
+
+1. Re-point `railiance01`'s checkouts to `forgejo-remote`, keeping `gitea` as the
+   rollback mirror the playbook specifies. Content diverges — `evidence-binder`
+   there is at `a715492` against the workstation's `9e3f4a6` — so this is a
+   reconcile, not a URL rewrite.
+2. Then set `STATEHUB_REGISTRAR=1` on the deployment.
+
+Reversing the order mints into the wrong lineage at fleet scale.
+
+**Open question worth answering first:** the sweep pod is running now against
+those 70 stale checkouts. Establish what it has been pushing to `gitea-remote`
+before changing anything.
+
 ## Re-register identifiers minted outside the registrar
 
 ```task