[linhdmn]

The parent-owned fields, and only those — the PRD version line, the PRD codebase version, the PRD footer stamp, the tracker's **Last synced:** line, the tracker Summary table, the tracker In Progress table — plus one measurement correction inside the wave's own section.

• PRD **Version:** 4.17-scheduled-reclaim → 4.19-data-hygiene
• PRD **Codebase Version:** 0.35.0 → 0.35.2 (cmd/leankg/VERSION is 0.35.2 since the release merge) — this is the same drift the previous reconciliation left behind, one release later
• the footer stamp and the **Last synced:** line now describe this wave and name its seven PRs (memory: content identity, bank compaction, fleet memory sweep, MCP bank delete #564, fix(index): a markdown heading stores its own text, not its descendants' #565, maintain: make the hourly pass do its job, and say what it did #566, store: give a new store a page that can hold three vectors #567, portfolioreg: an automatic registry prune, and a store whose index root moved is reported #568, fix(telemetry): sweep the ledger whatever the capture level, and let it shrink #570, fix(index): reconcile the store with HEAD, and report head_sync #571)
• the Summary counts: the nine-defect wave is counted in the DONE row, the data-hygiene wave is counted the same way, and neither is folded into the archive-inventory count
• the In Progress table: the nine-defect wave's row is closed (all nine merged) and the data-hygiene wave's row is added

Measurement correction. The FTS figures in the v4.19-scheduled-reclaim-real section were wrong, and are corrected here:

the live leankg store carried a 9.4 MB elements_fts_idx over 3,065 segments — 31 % of the 138 MB store

dbstat on a copy of the live store (with the -wal) says elements_fts_idx is 73,728 B (18 pages) — not 9.4 MB — and there is no "3,065 segments" figure in the store. The "31 %" belongs to the FTS tables as a whole (43,370,176 B of 138,678,272 B). What one compaction actually reclaims, measured by running the merged CompactFTS against a copy of the live store:

object	before	after
elements_fts_data	16,654,336	10,534,912
elements_fts_idx	73,728	40,960
keyword rows	11,584	11,584

6,152,192 B (6.15 MB) of merged segment space reclaimed, with every keyword row intact. The same correction is posted on PR #566.

The fix and its tests are unaffected; only the measured attribution was wrong.