feat(u4): a booth's lifetime is derived from its state, not from a boolean

`.forever` was the only way to say three different things — "this is durable",
"I have not answered yet", "I am still looking" — and the census said it was
carrying all three: 17 of 24 live booths (70%, up from 54% the day before).
Three of the four booths in the fleet awaiting an answer had been pinned by
hand as well, and 10 of the 17 were younger than the TTL, so the sentinel had
bought them nothing and was pressed pre-emptively.

Only the first meaning is what `keep` means. The other two are facts the
service already held and did not consult.

    KEPT       `.forever` present                      never swept  (unchanged)
    HELD       an open pick, or marks we cannot read   never swept  (new)
    EPHEMERAL  everything else                         24h          (unchanged)

Viewing is activity: a deliberately-served response from a booth's own page
route writes `.viewed`, which is a dotfile and not a `.lock` dotfile, so
`_newest_mtime` already counts it. There is no new arithmetic — `booth_age_seconds`,
`is_expired` and `expires_in` are unchanged. Machine reads are excluded on
purpose: an agent must not be able to hold its own booth open by polling for
the answer it is waiting on.

The hold is unbounded, and what makes that safe is visibility plus two exits
that already existed. Every surface whose chrome the Booth owns says
`held until answered` where the countdown was, and `booth rm` / the UI x /
`DELETE /b/<n>` take a held booth exactly as they take a kept one. A hold is
protection from the timer, never from the operator.

Three cross-frontier panels ran and each found a class the others could not:

  * the paraphrase panel found that two reads of one file are not one read of
    one state — the contract's `is_held(marks_for(c), read_error(c))` could
    resolve to `([], None)`, the pair that deletes. `hold_read` is one read.
  * the code-review panel found, 4-of-4, that the booth header's board branch
    rendered no lifetime at all; and that five of seven invariant tests passed
    under the change that defeats them.
  * the bug-hunt panel found four more paths where a failed read still
    authorized a delete, and a `record_view` that followed a planted symlink.

`is_held` became `hold_reason`, which returns the reason rather than a bool
beside a string that can disagree with it.

Prediction, to re-count on or after 2026-10-06: the `.forever` rate falls to
the booths that are genuinely durable references. Only 4 booths carry marks at
all, so this rests on both halves of the unit; a null result cannot distinguish
a wrong diagnosis from a habit that outlived its need.

406 tests (341 before). Contract: docs/contracts/u4_derived_lifetime.contract.md

ROADMAP.md

@@ -1,7 +1,7 @@
 # The Booth — roadmap
 
 Design: [`docs/design/information-architecture.md`](docs/design/information-architecture.md).
-Current version: `0.3.0` (U1, U2 and U5 landed; extracted from eshpfi 2026-09-21).
+Current version: `0.3.0` (U1, U2, U4 and U5 landed; extracted from eshpfi 2026-09-21).
 
 ## v1 target
 
@@ -13,7 +13,7 @@ defect — not a wish. The measurements are in the IA doc.
 | 1 | ~~**One item record**~~ — **landed `ce598b3`** | captions never reach the zoom view (never sent, not lost) | U1 |
 | 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 |
+| 4 | ~~**Derived lifetime**~~ — **landed** | 70% of booths on the `.forever` escape hatch (54% when first counted) | U4 |
 | 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,7 +22,7 @@ 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, U2 and U5 are landed.** U3 and U4 are unblocked and unstarted; U6 remains
+**U1, U2, U4 and U5 are landed.** U3 is unblocked and unstarted; U6 remains
 independent and unstarted; U7 waits on the rest.
 
 **U5's adoption is a measured prediction, not a finished result**, and it is
@@ -74,6 +74,12 @@ Where it already binds, and what the rule is in each case:
 | link board rows | pinned first, then newest-first |
 | a booth's announcement | not a collection — one flat record per booth, nothing to order (U5) |
 
+U4 added no ordered collection — a booth's lifetime is one state per booth,
+not a sequence — so the rule above did not need a new row. The three lifetime
+surfaces (index card, booth header, marks page) render through ONE macro
+precisely so they cannot disagree, which is the same property stated for
+ordering: one rule, one place, every surface reading it.
+
 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
 themselves, not just within; pairing by filename needs a rule for what happens