chore(workplan): measure CUST-WP-0068-T09 against the live projection

The reset now exists and has run fleet-wide, so T09 moves from wait to todo.
Every railiance-wp-* row is retired and its identifier released, meeting the
first acceptance clause.

The recorded 305 stale task rows no longer describes what is there: measured
against what the forge derives, 21 orphaned rows remain under live workplans
(0 open), 557 have no record_id at all (34 open), and 512 sit under workplans
retired today. Most of the 305 left the live surface with their workplans
rather than being repaired.

What remains is one change: reset_repository_projection still skips the tasks
of existing workplans, a restriction adopted when hub tasks had no canonical
identifier. They have one now, so the reason is gone.

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

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

@@ -323,7 +323,7 @@ By status the remainder is overwhelmingly closed history — 96 `finished`, 10
 
 ```task
 id: CUST-WP-0068-T09
-status: wait
+status: todo
 priority: medium
 ```
 
@@ -392,6 +392,41 @@ before the endpoint's real behaviour was understood; all eight tasks were alread
 Acceptance: no `railiance-wp-*` workplan row and no orphaned task row remains on
 central, all removed through re-derivation rather than deletion.
 
+**Measured 2026-08-28, after the ADR-012 reset ran fleet-wide.** Status moves
+from `wait` to `todo`: the blocker was that the reset did not exist, and it now
+exists, has run against all 120 repositories, and reports `noop` everywhere.
+
+The first clause is met. Every `railiance-wp-*` row is retired and its identifier
+released; none is live.
+
+The second is not, and the recorded figure of 305 no longer describes what is
+there. Measured against what the forge actually derives:
+
+| Count | What |
+|---|---|
+| 21 | task rows under a live workplan whose identifier the file no longer derives — **0 open** |
+| 557 | task rows under a live workplan with **no `record_id` at all** — 34 open |
+| 512 | task rows under workplans retired today; historical, not a live surface |
+
+Most of the 305 did not get fixed so much as leave the live surface: their
+workplans were retired during the ad-hoc requalification and prefix work, so
+their tasks went with them. That is a real reduction, not a bookkeeping one —
+those rows no longer describe current work — but it is not what the acceptance
+clause asked for.
+
+**What actually remains is one code change.** `reset_repository_projection`
+deliberately does not touch the tasks of a workplan that already exists
+(`STATE-WP-0083-T06`, when hub tasks carried no canonical identifier). They now
+carry one: 5522 of 6337 tasks have a `record_id`, and derivation qualifies bare
+`T01` against its workplan (2026-08-28), so the reason for the restriction is
+gone. Lifting it lets the same re-derivation that cleaned the workplans clean
+the tasks.
+
+The 557 without a `record_id` are a separate population and should not be swept
+into this one. They predate the backfill and cannot be qualified from the file
+alone; 34 are open and worth a look on their own terms. `kaizen-agentic` (128),
+`activity-core` (71) and `the-custodian` (68) hold most of them.
+
 ## Disposition of duplicate task identities (2026-08-26)
 
 Establishing task identity (`STATE-WP-0083-T06`) exposed 35 duplicate identities