feat(workplan): close STATE-WP-0083-T08 — 18 files repaired, none unparseable

Two shapes of one missing-newline defect: 16 with the closing delimiter fused
onto the last value, 2 with a value fused onto the following key. Only the
newline was inserted.

Forces a correction: state-hub-v0.1 and v0.2 were reported as hub-first records
with no backing file. They are CUST-WP-0000 and CUST-WP-0000b, which existed all
along and were unreadable — the claim came from a parser's silence rather than a
check against the directory.

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

@@ -403,7 +403,7 @@ Two things this exposed, neither yet addressed:
 
 ```task
 id: STATE-WP-0083-T08
-status: todo
+status: done
 priority: high
 ```
 
@@ -443,3 +443,32 @@ diff no longer proposes retiring live workplans.
 Acceptance: no workplan file yields empty frontmatter while starting with `---`;
 the reset diff for each affected repository proposes retiring only records whose
 backing file genuinely no longer exists.
+
+**Done (2026-08-26).** All 18 repaired across 8 repositories; **zero workplan
+files now yield empty frontmatter**. Previously invisible workplans derive again:
+`KONT-WP-0015`, `CUST-WP-0000`, `CE-WP-0001` and the rest.
+
+Two shapes of one defect, both a missing newline:
+
+| Count | Shape | Example |
+|---|---|---|
+| 16 | closing delimiter fused onto the last value | `- KONT-WP-0016---` |
+| 2 | a value fused onto the following key | `…v1.3.0state_hub_task_id: …` |
+
+Only the newline was inserted; no value was altered, and the diff on each file is
+one line split into two.
+
+**A correction this forces.** `state-hub-v0.1` and `state-hub-v0.2` were reported
+earlier as genuine hub-first records with no backing file, and dispositioned on
+that basis. They are `CUST-WP-0000` and `CUST-WP-0000b` — files that existed all
+along and were unreadable. The claim was wrong because "no file backs this
+record" was inferred from a parser's silence rather than checked against the
+directory.
+
+**The ordering bug in the repair itself is worth recording**, since it is the
+same mistake in miniature. The first version only looked for a fused delimiter
+when no `\n---` existed anywhere in the file. Five `citation-evidence` files have
+a horizontal rule in the body, so a delimiter *was* found — just the wrong one —
+and the real defect was hidden behind it. Checking whether the frontmatter
+*parses* before trusting the delimiter position fixed it, taking the count from
+11 repairable to 18.