REPORT: record the where-felhom-stands refresh, the three downgrades and the renderer defect

NOT WALKED moved 32 -> 35 of 55, which the repo checklist asks be stated. Also records the
hardcoded-sha defect found in render_stands.py and the positive control run on check_stands.py.

REPORT.md

@@ -346,3 +346,38 @@ red-proofs. The session did not run short.
 - **The safety dump still overwrites the unit's own DB dump before renaming it** (R-361, out of scope)
   — visible in this session's own evidence, where `romm`'s `db-dumps/` holds both a `pre-restore-*` and
   the regular dump.
+
+---
+
+## 15. THE PICTURE — `where-felhom-stands` brought up to date (same day, after the fixes)
+
+Regenerated from `where-felhom-stands.yaml` (the HTML is a build product; the YAML is the source).
+**Eight claims re-checked, three moved — all downward.**
+
+| claim | was | now | why |
+|---|---|---|---|
+| `backup.offsite` | walked | **partial** | "18 snapshots, daily, unbroken" was true on 2026-08-09 and false by 2026-08-21 — the next snapshot after it was put there by hand, twelve days later, and nothing reported the gap |
+| `fail.wiped-reinstalled.data` | walked | **partial** | a real reinstall orphans BOTH off-premises tiers: restic silently for 12 days (R-193), and the pre-reinstall PBS archives cannot be opened by the rebuilt box at all (R-366) |
+| `backup.fill-warning` | walked | **partial** | the warning fires correctly, but once a day — a filesystem filling at 03:31 is unannounced for ~24 h, and it was watched staying silent while a volume sat at 99% |
+
+**Held, with their notes rewritten:** `backup.tier1` and `recover.byte-identical` now carry the
+R-355/R-354 story *and* their fixes; `backup.restore-proof` stays grey for a sharper reason (its
+archives are orphaned, not merely untested); `backup.sikeres` gained two fresh instances;
+`fail.customer-self-restore` records that R-356 blocks 40 of 53 apps regardless of who is driving.
+
+**`unproven.py --summary` moved, and the checklist asks that it be said:**
+**NOT WALKED went from 32 of 55 to 35 of 55.** That is the three downgrades above. Nothing was raised
+— the dataset's own rule forbids raising a status here, and nothing needed it.
+
+### A defect found in the page's own toolchain
+
+**The rendered header cited the wrong commits and would have gone on doing so.** `render_stands.py`
+parsed `verified_on` from the YAML but had the three commit shas **hardcoded**, so the page printed
+the 2026-08-09 commits while the dataset said 2026-08-22. That is precisely the stale-build-product
+failure the renderer's own docstring says it exists to prevent. Parsed now, literals gone from both
+the script and the output, checked. The count beside it also read *"15 status(es) moved in that pass"*
+when 15 was every recorded move ever accumulated; it now separates the two numbers.
+
+**`check_stands.py` was proven able to convict before its OK was accepted:** a claim marked `missing`
+flipped to `walked` in a scratch copy fired rule 5 by name (`use.dlna: status 'walked' but NO evidence
+document cited`), and the real file still passed. Gates all OK; CI **id=380 / run_number=248**, green.