fix(probe): the disclosure-opening loop was manufacturing its own findings

`page.locator("details:not([open])").all()` hands back POSITIONAL locators
that re-resolve against the current DOM, and `:not([open])` stops matching
an element the moment it is opened — so opening them one at a time shrinks
the set underneath the indices and leaves some closed. Those then report
OCCLUDED, which is exactly the false-positive class the block was added to
remove. One on booth-redesign, three on cr123a-to-d-sleeve, one on
denoise-first-run, and invisible as a bug because a false positive is
shaped like a finding.

Measured both hypotheses rather than guessing between them: per-element
loop against a single document-wide evaluate, at 150 ms and 1000 ms settle.
The loop reports them at either wait; the single pass reports none at
either. The variable was the method, not the timing.

One evaluate over the whole document now. All three pages clean.

Also carries the ROADMAP U5 row, the two-panel record in
persistent-memory.d/, and the memory index line for it.

ROADMAP.md

@@ -1,7 +1,7 @@
 # The Booth — roadmap
 
 Design: [`docs/design/information-architecture.md`](docs/design/information-architecture.md).
-Current version: `0.2.1` (U1 + U2 landed; extracted from eshpfi 2026-09-21).
+Current version: `0.3.0` (U1, U2 and U5 landed; extracted from eshpfi 2026-09-21).
 
 ## v1 target
 
@@ -14,7 +14,7 @@ defect — not a wish. The measurements are in the IA doc.
 | 2 | ~~**Marks**~~ — **landed `c7f9437`, released `v0.2.0`** | 5 mechanisms for 1 job; operator→session loop runs through chat | U2 |
 | 3 | **Declared embed seam** — `/_booth/embed.js`, chrome mounts via DOM | 6 regexes injected into arbitrary author HTML, load-bearing for asks | U3 |
 | 4 | **Derived lifetime** — open marks pin; viewing is activity | 54% of booths on the `.forever` escape hatch | U4 |
-| 5 | **Self-announcing booths** — `.booth.json`, provenance on the index | job 5 had no home, so it lived on the link board as 145 dead rows | U5 |
+| 5 | ~~**Self-announcing booths**~~ — **landed `c015a91`, released `v0.3.0`** | job 5 had no home, so it lived on the link board as 145 dead rows | U5 |
 | 6 | **Benches** — registry, identity, enforced rule, migration | 69% link-board rot; the same bench posted 5× | U6 |
 | 7 | **Navigation at 270 items** — sections, rail, filters, grid keyboard | one flat wall; subfolder structure discarded at render | U7 |
 
@@ -22,8 +22,18 @@ Ordering is dependency-driven, not priority-driven: **U1 → U2 → {U3, U4, U5}
 U7**, with **U6 independent** of all of them (different storage, different
 surface) and therefore the safest thing to land first or in parallel.
 
-**U1 and U2 are landed**, which unblocks U3, U4 and U5 — all three read marks.
-**U5 is next** (operator, 2026-09-21). U6 remains independent and unstarted.
+**U1, U2 and U5 are landed.** U3 and U4 are unblocked and unstarted; U6 remains
+independent and unstarted; U7 waits on the rest.
+
+**U5's adoption is a measured prediction, not a finished result.** The operator
+declined a fleetwide announcement so that adoption could be told apart from
+design: the convention propagates through the README alone, and the count of
+booths carrying a `.booth.json` gets re-measured on **2026-09-29** against a
+baseline of **0 of 26** at landing. A near-zero count means nobody heard about
+it — an adoption failure, fixed by announcing — which is a different thing from
+nobody wanting it. Same instrument as U4's `.forever` prediction below.
+
+    find ~/booth-data -maxdepth 2 -name .booth.json | wc -l
 
 ### Cross-cutting invariant — deterministic order, everywhere
 
@@ -53,6 +63,7 @@ Where it already binds, and what the rule is in each case:
 | marks in a booth | `(created, id)` — time, with the id as tie-break so two marks written in the same second cannot swap |
 | legacy ask import | `(mtime, name)`, which is the order `list_asks` gave them |
 | link board rows | pinned first, then newest-first |
+| a booth's announcement | not a collection — one flat record per booth, nothing to order (U5) |
 
 Where it is still to be decided, and must be before the unit ships: **U7's
 section ordering and its compare pairing** (sections need a stated order among