feat(workplan): record the central backfill and the short-task-id defect

5248 rows identified but only 5100 identities distinct: bare T01 task ids stored
as canonical gave every workplan's first task one identity, 51 ids across 148
rows. The backfill's conflict check could not see it — it detects one UUID
claimed by two ids, and this was the inverse — so it surfaced only because the
two counts did not reconcile.

Central now holds 5112 of 5974 identified, 5077 distinct. The remaining 34
duplicates are unqualified ad-hoc ids reused across repositories, the problem
CUST-WP-0066 closed for new records only.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006

workplans/STATE-WP-0083-forge-derived-projection-reset.md

@@ -268,6 +268,44 @@ Only then may `T03` be extended to tasks of existing workplans, which is a
 further change with its own verification. `CUST-WP-0068-T09` is therefore two
 moves away, not one.
 
+**Backfill run against central (2026-08-26), and a defect it exposed.**
+
+The first implementation read local filesystem paths. Central has no workstation
+checkout and must not depend on one — `ADR-012` decision 1 makes the forge the
+projection source — and the point became concrete rather than theoretical:
+central's Postgres is unreachable from the workstation, since the tunnel carries
+HTTP only. A forge-sourced variant now clones each repository in-cluster and
+reads the pairing from what the forge holds.
+
+Dry run across 121 repositories: 1094 files, 5620 pairs, 5248 to update, 372
+file-declared UUIDs central does not hold, **zero conflicts**. The count
+differing from the cache's 4456 of 6073 was the check that mattered — central
+holds the re-keyed records the cache never had, so a *matching* number would have
+meant cache state was leaking in. The forge scan reading 1094 files against the
+workstation's 1104 is the preliminary-overlay distinction showing up in the
+numbers.
+
+**Then applied, and wrong.** 5248 rows were identified but only 5100 identities
+were distinct. A task id written as a bare `T01` is unique only inside its own
+workplan; stored as canonical it gave every workplan's first task one identity.
+51 such ids landed on 148 rows.
+
+The backfill's own conflict detection could not see it: it checks one UUID
+claimed by two ids, and this was the inverse. It surfaced only because the
+identified count and the distinct count did not reconcile — a check that could
+easily have been skipped after a dry run reporting zero conflicts.
+
+Short ids are now qualified as `WORKPLAN-ID-T01`, and a short id in a file with
+no workplan id gets no identity at all. The 136 affected rows on central were
+cleared for reassignment, since the backfill never overwrites an existing
+identity.
+
+**Central now: 5112 of 5974 identified, 5077 distinct.** The remaining 34
+duplicates are not from this work. They are unqualified ad-hoc ids reused across
+repositories — `ADHOC-2026-07-02-T01` exists in three workplans — which is the
+problem `CUST-WP-0066` closed for new records while existing ones kept their
+unqualified ids. They need their own disposition.
+
 
 ## Restore a migration mechanism for central