fix(scripts): teach check:durability-log-level a declared failure-propagation vocabulary (#5241)

The gate had two legal answers for a catch guarding a durability-critical
callee — rethrow, or log at `error` — and no way to express the third:
the failure was handed to the CALLER. AGENTS.md's own judgment question
("does the system still look normal from the outside?") answers NO for
that shape, so it is not a degradation at all.

#4754 hit this the moment `saveMetaItem` entered the vocabulary: three of
its four hits were propagation, not degradation, and had to be parked in
`durability-degradation.baseline.json` — entries for CORRECT code, in a
shrink-only ledger whose header calls every line debt. Worse, the cheapest
way out at `meta.ts` was to bolt on a `logger.error` on a path whose common
case is a rejected request: one durability `error` per bad keystroke, the
mirror-image failure AGENTS.md names.

The vocabulary is DECLARED, never guessed, and the declaration only supplies
the NAME — the checker still proves the STRUCTURE (every path out of the
catch delivers the failure), so a declaration cannot become a baseline entry
wearing a friendlier name:

  - FAILURE_PROPAGATION_CALLEES — repo-wide names (`errorFromThrown`), split
    by how they deliver: `via: 'return'` (the value IS the answer, so it only
    counts inside a `return`) vs `via: 'effect'` (the call IS the delivery).
  - FAILURE_PROPAGATION_SITES — function-scoped names for the second shape:
    a batch whose contract is a per-item outcome report, delivering through
    `record(...)` / `failed.push(...)`. Keyed by file plus enclosing FUNCTION,
    not by file: `protocol.ts` is nine thousand lines and a file-wide licence
    for `saveMetaItem` would hide the next #4669. Entries are staleness-checked.

`catchDeliversFailure()` is conservative by construction: it can carry a
delivery forward but never invent one, and any exit it cannot prove delivered
counts as an escape — "cannot prove" reads as "does not deliver", which judges
the seam instead of excusing it.

Both #5241 baseline entries went stale and are deleted; the ledger is now
empty, which is its intended steady state. No production code changed — the
three sites were correct all along.

Self-test grows 19 -> 35 cases, pinning both halves of the rule: partial
propagation, an envelope built but never returned, a delivery in a later
callback, a report written on one branch only, an undeclared report shape,
and a site declaration keyed to a different function all still flag.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V7WetGmnfoXNn8cLieKKmx

Author: claude

AGENTS.md

@@ -608,6 +608,22 @@ mirror-image failure: it trains everyone to skim `error`, which is what made the
 composition branch is usually functional and usually belongs at `warn`; a `catch`
 around a write, a DDL call, or a store initialization is where this rule bites.
 
+**A failure handed to the CALLER is not a degradation at all** — this is the
+third legal answer, and forgetting it is how the mirror-image failure gets
+written. Ask the judgment question honestly: a `/meta` PUT whose `catch` answers
+`errorFromThrown(e, 400)`, or a batch whose contract IS a per-item outcome report
+and whose `catch` writes the failure into it, does **not** look normal from the
+outside — the requester was told, per item, that the write did not land. That is
+already louder than a log line. Do **not** bolt a `logger.error` onto such a
+site: the common case on a validation path is an author submitting an off-spec
+body, so you would emit one durability `error` per rejected keystroke, which is
+exactly what makes `error` unreadable. Declare **how it delivers** instead —
+`FAILURE_PROPAGATION_CALLEES` (repo-wide names like `errorFromThrown`) or the
+function-scoped `FAILURE_PROPAGATION_SITES` (local report sinks, whose names mean
+nothing repo-wide) in the checker, which then proves structurally that *every*
+path out of the `catch` delivers. #5241 added it after #4754 was forced to park
+three correct sites in the baseline for want of a way to say this.
+
 **It has teeth** (a rule this repo only writes down is the very "declared ≠
 enforced" shape it keeps paying to fix): `pnpm check:durability-log-level` walks
 the AST for `catch` blocks guarding a declared vocabulary of durability-critical
@@ -617,7 +633,11 @@ known ones from regressing. Found a new one? Add it to
 `DURABILITY_CRITICAL_CALLEES` in `scripts/check-durability-degradation-log-level.mjs`
 in the same PR that fixes it. Accepted exceptions live in
 `scripts/durability-degradation.baseline.json`, hand-edited with a reason and
-shrink-only.
+shrink-only — and that file is currently **empty**, which is its intended steady
+state: an entry there means a real degradation nobody has fixed yet, never a site
+the gate merely cannot classify. If a red seam turns out to hand its failure to
+the caller, declare the propagation vocabulary above; do not baseline correct
+code.
 
 ---