feat(workplan): record CUST-WP-0068 recovery outcome — 964 of 1075 records

Central 670 -> 1018 workplans; cache-only gap 426 -> 111.

T06 was scoped as an identifier-migration decision and that framing was wrong.
Two defects did most of the blocking: 50 repositories carried retired
gitea-remote URLs on central so fix-consistency could not match them, and the
registrar was blind to records that had an identifier but were absent from the
hub. Both were masked by a generic error whose real message sat in a child
process's stderr.

Also records the repo-wide re-key that severed eight working identifiers on
kaizen-agentic, and the rule now enforced in code to prevent it.

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

workplans/CUST-WP-0068-cache-only-work-record-recovery.md

@@ -251,6 +251,53 @@ Acceptance: registration records a backing file in one pass; the fleet-wide
 count of file-less workplans is re-measured and explained; every remaining true
 orphan is repaired, given a file, or dropped in writing.
 
+## Outcome so far (2026-08-25)
+
+**964 of 1075 work records recovered. Central went from 670 to 1018 workplans;
+the cache-only gap fell from 426 to 111.**
+
+`T06` was scoped as an identifier-migration decision. That framing was wrong,
+and the re-key it authorised turned out to be the smaller half. Two defects were
+doing most of the blocking, and both were invisible behind a generic
+`"State Hub reconciliation did not assign every requested identifier"` — the
+real message sat in a child process's stderr the whole time:
+
+1. **50 repositories carried retired `gitea-remote:` URLs on central.**
+   `fix-consistency` matches a checkout to its record *by* `remote_url`, so it
+   could not find them and refused to register any of their work records. The
+   forge migration updated every working copy and never the hub. `repo-onboard`
+   now corrects a stale remote from the working copy's origin; 53 were fixed.
+
+2. **The registrar was blind to "identified but absent".** It looked only for
+   *missing* identifiers, so a record whose derived identifier was already in
+   the file but absent from central short-circuited to `noop`. C-06 handles that
+   case and marks it fixable; only the early return stood in the way.
+
+The re-key itself was then necessary but narrow: C-06 registers an absent record
+only when its identifier is the derived one, so 139 pre-`ADR-007` identifiers had
+to be re-keyed before they could be registered.
+
+**A mistake worth recording.** The first re-key script ran repo-wide and
+overwrote the identifiers of eight workplans on `kaizen-agentic` that were
+correctly registered, severing them from their live records. They were restored
+by matching canonical ids against central's slugs. The rule — *never re-key a
+record the hub already holds* — is now enforced in the script rather than
+remembered, and it correctly refused five duplicate-registration cases on the
+full run. `kaizen-agentic` deserves an independent look, since the repair was
+verified only by the person who caused the damage.
+
+**The 111 that remain**, all in eight repositories:
+
+| Count | Repository | Cause |
+|---|---|---|
+| 50 | `clay-borg` | files use `kind: product`, not `type: workplan` — nothing parses them (`T04`) |
+| 12 | `glas-harness`, `rein-aharness`, `rein-openweights` | identifiers the canon registry rejects (`T03`) |
+| 6 | `evidence-anchor`, `the-custodian`, `sand-boxer`, `state-hub` | mixed residue, needs case-by-case review |
+| — | `railiance-platform`, `railiance-apps` | the retired `RAILIANCE-WP` family prefix: files in two repositories whose records central attributes to a third. An identity decision, not a re-key |
+
+By status the remainder is overwhelmingly closed history — 96 `finished`, 10
+`archived` — with only 2 `active`, 2 `blocked` and 1 `proposed` still live.
+
 ## Converge and retire the cache database
 
 ```task