fix(620): signal corpus size per RECORD; the aggregate becomes an unthresholded trend

Squashed from 7 commits (4 review rounds) to keep the rebase onto #621 tractable; the
full round-by-round history is on PR #642.

corpus was 5658/5600 — over budget and warning again — 3h35m after #619 put it at 5228,
with nobody consolidating anything.

So this does NOT re-baseline. An aggregate over a monotonically growing corpus can only
ratchet; that is the "permanently red, therefore no signal" state #542 re-baselined away
from, and growth is not even a smooth rate to plan against (the corpus FELL from 5089 to
5042 across four days, then gained 427 in one evening as two large records landed).

Replaces it with a per-record prose ceiling (default 60), non-blocking, naming each
record over it — not monotonic, so it can go red AND green, and it points at a file. The
aggregate is still printed as an unthresholded trend notice, with record prose and
non-record scaffolding reported separately because they are not the same unit. The
GENERATED catalog is no longer counted at all: it gains one row per record and no
consolidation can shrink it, which made the metric partly a record COUNT in a line-count
costume.

The calibration test took FOUR versions, and the failures are the durable lesson:
  v1  true by construction (`max(under) <= 60 < min(over)` over lists built by that test)
  v2  a gap WIDTH — a ceiling of 200 also sits in a wide gap, so it passed
  v3  fraction band + "clear air" vs the nearest record above — hostage to an unrelated
      record: one ordinary 62-line addition reddened it with the ceiling correctly
      placed, and the only remedy was to RAISE the ceiling. That is this very treadmill,
      as a hard failure in what #631 makes a blocking job.
  v4  `p90 <= ceiling <= p95` — the property stated directly and scale-free.
Two rules recorded: a guard test must depend only on the thing it guards, and a threshold
over a growing population must be expressed in that population's own terms.

Candidates: all over-ceiling records assessed, each actioned or declined with a reason.
The largest (scan.libraryfolder-unique-identity, 230 lines) is a legitimate DECLINE — a
dozen-odd distinct traps whose only copy that is. Nothing pruned, so no archive or
supersession was required. An automated redundancy metric is explicitly rejected.

Also: `--budget` is accepted but announces its retirement rather than no-opping silently;
the dead `budget_ok` parameter is gone; and five "untresholded" typos are fixed, one of
which was propagating into the generated catalog row and MemPalace's per-key drawer.

Refs #620

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/decisions.md

@@ -50,9 +50,11 @@ it after any status change; CI's `decisions lifecycle` job fails on drift (`--ch
 
 **Enforcement**: `scripts/decisions_validate.py` checks metadata well-formedness (including a required
 `Signals:` line), one-active-record-per-key, reciprocal links, that no record vanishes from the active
-set without an archive copy, that the active catalog is in sync, and an aggregate active-corpus line
-budget (replaces the old 1800-line
-floor on this single file). The Husky `pre-commit` hook runs the structural checks over the working
+set without an archive copy, and that the active catalog is in sync. Separately, and as a
+NON-BLOCKING warning rather than an error, it reports a per-record prose ceiling (ersatztv#620).
+The aggregate active-corpus line budget that used to sit in this list — itself the replacement for
+an older 1800-line floor on this single file — is RETIRED: the total is now printed as an
+unthresholded trend notice only. The Husky `pre-commit` hook runs the structural checks over the working
 tree; the CI `decisions lifecycle` job additionally runs the body-diff check with `--base`/`--head`.
 
 **`Decisions-Edit: yes`** (a git **trailer** — the message's final paragraph, alongside