FABRIC-3.5.md §XL: item 40 settled -- preserve the consumption model, ledger the sink

New evidence found while settling this reverses §XXXVIII's framing.
messaging.4th block 5025, immediately above MSG-REAP, states outright
that K reap only fires at heat=0 so the freed contribution is 0, and
anticipates that a force-reap would require explicit K redistribution.
The zero-return at natural reap is a documented design note, not an
oversight: heat is modelled as consumed over a message's life rather than
held as a refundable deposit.

So §XXXVIII's trace stands exactly -- decay drains the field, reap
returns nothing, the eviction guard is bypassed -- but its interpretation
does not. The word leak is withdrawn, along with its recommendation to
change the economics as part of this reshuffle.

Two further roles for message heat turned up and both corroborate the
model: MSG-NACK-LAST halves it, so a rejected message ages twice as fast,
a penalty in the same currency; and delivery order does not consult it at
all, so changing it cannot perturb sequencing.

Ruling: kernel-Hermes preserves the economy exactly and additionally
records what it consumes, making the Stadium invariant read patron heat
plus reservoir plus consumed equals Q48_ONE. That is what makes item 41's
stadium_conserved() possible at all -- without a consumed term a checker
over a designed sink reports non-conservation as normal operation, which
forces a tolerance that hides real bugs. §XXXVII.3's counter is therefore
vindicated rather than deleted, and for a better reason than it was
introduced for.

Declines to separate reservation from age now, despite it being the
better architecture, on scope, measurement comparability, and the fact
that this subsystem yielded two new surprises while a third was being
settled.

Names but does not answer the real question: nothing replenishes a
reservoir, so a long-lived VM's send capacity declines monotonically, and
batched pumping accelerates it with fleet size. Fourth instance of latent
at Tripod scale, visible at fleet scale. Filed as outside this reshuffle.

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

FABRIC-3.5.md

@@ -4223,3 +4223,110 @@ future reader will conflate them exactly as §XV.4 and §XXXIV.6 did.**
 - ⬜ **Item 42, NEW** — qualify "K"/"conservation" throughout the docs (§XXXIX.6). Folds into
   item 13.
 - ⬜ **Item 40** unchanged — separate reservation from age (§XXXVIII.4).
+
+---
+
+## XL. Item 40 SETTLED: preserve the consumption model, ledger the sink — and a correction to §XXXVIII's framing
+
+§XXXVIII.4 recommended separating reservation from age to remove what it called a leak.
+**Further evidence found while settling this says the behaviour is a deliberate model, not a
+defect — and the recommendation is revised accordingly.**
+
+### XL.1 — The authors knew. It is documented at the reap site.
+
+`messaging.4th`, block 5025, immediately above `MSG-REAP`:
+
+> `( K reap only fires at heat=0: freed K contribution is 0. )`
+> `( Force-reap not yet implemented. If added: explicit )`
+> `( K redistribution will be required here. )`
+
+**That is not an oversight; it is a design note.** It states outright that reaping returns zero,
+and anticipates that a *force*-reap — freeing a message before it has cooled — would need
+"explicit K redistribution," i.e. handing the remaining heat back. **The zero-return at natural
+reap is intended: the heat is modelled as consumed over the message's life, not held as a
+refundable deposit.**
+
+### XL.2 — CORRECTION to §XXXVIII
+
+§XXXVIII called it "a real, structural leak" and framed the two-meanings conflation as an
+error. **That framing was wrong.** The trace in §XXXVIII stands exactly — decay drains the
+field, reap returns nothing, the eviction guard is bypassed — **but the interpretation does
+not.** It is a consumption economy, documented where it happens, and §XXXVIII did not find that
+comment.
+
+**What survives from §XXXVIII:** the mechanism, the arithmetic, and the observation that
+nothing replenishes. **What is withdrawn:** the word "leak," and the §XXXVIII.4 recommendation
+to change the economics as part of this reshuffle.
+
+### XL.3 — Two further roles for message heat, both consistent with the model
+
+- **`MSG-NACK-LAST` halves it** (`messaging.4th:432`): `DUP MSG-HEAT@ 2 / OVER MSG-HEAT!`. A
+  rejected message ages **twice as fast** — a penalty expressed in the same currency. This only
+  makes sense if heat is a time-to-live, reinforcing §XL.1.
+- **Delivery order does *not* use it.** `MSG-DELIVER-ALL` scans the arena in slot order and
+  delivers anything not already delivered or nacked — **no heat comparison anywhere.** So heat
+  plays no scheduling role, which is consistent with §XV.3 (nothing owns turn order) and means
+  changing it cannot perturb delivery sequencing.
+
+### XL.4 — RULING: keep the model; make the sink explicit
+
+> **Kernel-Hermes preserves the consumption economy exactly — heat decays, natural reap returns
+> nothing — and additionally *records what it consumes*.**
+
+The Stadium per-VM invariant then reads:
+
+```
+  Σ(resident patron heat) + reservoir + consumed  ==  Q48_ONE
+```
+
+**This is what makes item 41's `stadium_conserved()` possible at all.** Without a `consumed`
+term, a checker over a system with a designed sink reports non-conservation as *normal
+operation* — which forces a tolerance that hides real bugs, or makes the checker useless.
+**With it, the invariant is exact and the epsilon stays zero.**
+
+**A pleasing arc worth recording:** §XXXVII.3 invented a `decayed` counter to keep the ledger
+exact. §XXXVIII.5 proposed deleting it by separating the fields. **It turns out to be the thing
+that makes Stadium conservation checkable** — the counter was right, and for a better reason
+than the one it was introduced for.
+
+### XL.5 — Why not separate the fields now, despite it being cleaner
+
+§XXXVIII.4's design is still the better *architecture*. It is rejected for **this** reshuffle on
+three grounds, none of them about elegance:
+
+1. **Scope.** This document's own discipline is "a reorganization, not an invention." Changing
+   the fleet's economic model is an invention, and it would be smuggled in under a relocation.
+2. **Measurement comparability.** Every DoE campaign and the patent-supporting figures were
+   taken under the current economics. §XXV.1 relieves some of that by rewriting the DoE's
+   invocative paths, but **it does not make a behavioural change to the economy free.**
+3. **The economics are not understood well enough to change safely.** §XL.3 found two
+   additional roles for message heat *while settling a question about a third*. That is a
+   subsystem still yielding surprises, and changing its semantics mid-reshuffle is how a
+   relocation becomes an outage.
+
+### XL.6 — The question that is real and is deliberately not answered here
+
+**Nothing replenishes a Stadium reservoir.** Each VM's quota starts at `Q48_ONE` and thereafter
+only moves within that VM or is consumed. So a long-lived VM's capacity to send **declines
+monotonically**, and the decline accelerates with fleet size — batched pumping (§XXII's
+`SK_MSG_PUMP_BATCH`) means longer queue residency, more decay per message, more consumption.
+
+**This is the fourth instance of this reshuffle's recurring pattern:** latent at Tripod scale,
+visible at fleet scale — after the pump's O(N) walk, `SK_SWITCH_MAX_SLOTS`, and
+`MSG-TOTAL-HEAT`'s arena scan.
+
+**Whether a reservoir should ever replenish is a genuine open design question about the
+compudynamics**, not a reshuffle decision. **Punch item 43, explicitly outside this work**, and
+properly `FABRIC-3.md`'s or a successor's topic. Recorded here so it is not lost — and so that
+whoever meets a VM that has quietly stopped being able to send knows where it was first named.
+
+### XL.7 — Punch list
+
+- ✅ **Item 40 — SETTLED** (§XL): preserve the consumption model; kernel-Hermes ledgers
+  `consumed`; §XXXVIII's "leak" framing withdrawn and its recommendation revised.
+- ✅ **Item 41 clarified** — `stadium_conserved()` checks
+  `Σ patron + reservoir + consumed == Q48_ONE`, exactly, epsilon zero.
+- ✅ **§XXXVII.3's counter vindicated** — kept, and now load-bearing for §XL.4.
+- ⬜ **Item 43, NEW, outside this reshuffle** — should a Stadium reservoir ever replenish?
+  (§XL.6)
+- Items 32–35, 37, 42 unchanged.