FABRIC.md: fix GAP-D1 through D3, close out §25.7.1

D1  The three passages still arguing from the K-denominator justification that
    §2's correction removed: §17.3's opening now cites density's need for a
    volume (§19.2); §17.5's sizing argument re-grounded on mass swamping and
    §23.1's abolition of by-reference payloads; §17.6(d)'s bullet no longer
    cites §2 for a claim §2 explicitly disavows.
D2  §19.6 #1 and #2 struck through as resolved (#1 by §23.1 with the residue
    scheduled as item 1.12; #2 by §24.3), matching §17.4's convention.
D3  §20.3's stale LEANING now points at §21's DECIDED.

§25.7.1's status updated: all fourteen findings closed. A1 ruled and applied,
B1/B2 verified against the tree and fixed into their items, B3/C1-C7/D1-D3
applied. The findings text is preserved as the record of what was found.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

FABRIC.md

@@ -715,7 +715,9 @@ This is worth stating plainly because "reap" reads as "free" and here it does no
 
 §16.3 left words as the unresolved patron. Pinning all of them resolves nothing — several
 hundred permanently resident, largely inert entries is the §9 screen-cell failure with a
-different label, and it wastes the bounded capacity that gives K a fixed denominator.
+different label, and it wastes the bounded capacity that density needs as its volume
+(§19.2; this sentence originally cited the K-denominator justification that §2's
+correction removed — D1).
 
 The better reading applies §5 unchanged. Storage sits beneath the Stadium. The **full
 dictionary sits beneath it too**, and only **hot words are on the floor**.
@@ -880,10 +882,13 @@ patron, the grid is not.
 #### The sizing argument, independently
 
 A framebuffer is several megabytes of fixed device memory. Making it a patron means either
-blowing the bounded capacity that gives K a fixed denominator (§2), or forcing the
-by-reference payload path to exist for exactly one pathological object — which would decide
-§12 Q1's payload threshold on the worst possible case. Sizing a design around its single
-largest outlier is how the header ends up wrong for the other ten thousand entries.
+swamping the bounded capacity (§2) — as mass, it would dwarf every other patron and make
+density comparisons meaningless — or forcing a by-reference payload path to exist for
+exactly one pathological object, which §23.1 has since abolished for patrons entirely.
+Sizing a design around its single largest outlier is how the header ends up wrong for the
+other ten thousand entries. *(This paragraph originally leaned on the K-denominator
+justification removed from §2 and on the pre-§23.1 payload framing; the conclusion is
+unchanged — D1.)*
 
 #### Not a patron does not mean no physics
 
@@ -941,8 +946,10 @@ Per-entry heap allocation gives that up and takes several things with it:
 
 - **The finite state space.** Bounded capacity is what makes induction over the Stadium
   straightforward and what puts model checking on the table alongside theorem proving.
-- **§2's hard outer wall.** Without an inescapable bound, K is bookkeeping rather than a
-  conservation law — §2 says this in as many words.
+- **§2's hard outer wall.** The bound is what gives density a volume to be dense within
+  (§19.2) and §13 its finite index set. *(This bullet originally read "Without an
+  inescapable bound, K is bookkeeping — §2 says this in as many words"; §2 no longer says
+  that, and §20.2 established conservation is falsifiable regardless of the bound — D1.)*
 - **The engine's simplicity.** This is a freestanding kernel with `kmalloc.c` / `pmm.c`
   and no libc. Allocation in the reap path means the engine can fail to allocate, which
   means the engine needs a failure mode, which means it is no longer the thing §3
@@ -1258,14 +1265,14 @@ noun was overloaded.
 
 ### 19.6 Open
 
-1. **What is mass, exactly, for each patron?** The definition is "cells occupied," which
-   requires §12 Q1 (payload threshold — inline versus by reference) and §12 Q2 (header
-   size) to be settled first. A patron stored by reference has small mass regardless of
-   payload size, which may be right or may be a loophole — a 1 MB block held by reference
-   would occupy one cell and read as dense. This needs deciding.
-2. **Is mass constant for a patron's lifetime?** §17.4 Q4 (do patrons mutate in place)
-   decides this. If mass can change while a patron is resident, density is not stable and
-   ranking may thrash.
+1. ~~**What is mass, exactly, for each patron?**~~ **RESOLVED by §23.1** — the by-reference
+   loophole is closed: if the payload is in the Stadium it counts toward mass, and what is
+   not in the Stadium is not resident. The one residue — whether continuation cells are
+   contiguous or linked, which shifts every large patron's mass — is §23.4 #4, scheduled as
+   item 1.12. (D2)
+2. ~~**Is mass constant for a patron's lifetime?**~~ **RESOLVED by §24.3** — mass changes
+   only through an arbitrated transfer, never through traffic, so density is stable between
+   transfers and §13 gets a mass function that changes at enumerable points. (D2)
 3. **How does traffic transfer heat between patrons, concretely?** `vm_physics_touch()`
    does this today for VMs, but it scales the transfer by wall-clock elapsed time
    (`capsule_vm_physics.c:272`), which §18.5 forbids for anything influencing patron state.
@@ -1369,7 +1376,8 @@ This does not close Q6 by itself, but it changes the question. The choice is no
 between two greenfield designs; it is whether to formalise a nesting that is already half
 built, or to collapse it into a single region and discard the level that works.
 
-**LEANING nested.** See §20.5 for what still has to be settled.
+~~**LEANING nested.**~~ **DECIDED nested in §21**, written immediately after this section
+(D3). See §20.5 for what still had to be settled.
 
 ### 20.4 A VM's mass is the capacity share Hera allocated it — PROPOSAL
 
@@ -2300,8 +2308,13 @@ so.*
 ### 25.7.1 Second review pass — 2026-08-03, pre-coding. Awaiting rulings.
 
 *A full re-read of this document as it stood after the first review's corrections, looking
-for what would break a lower-capability model working the punch list. Nothing here has been
-fixed. GAP-A1 needs a ruling before item 0.8 is coded; the rest are queued for triage.*
+for what would break a lower-capability model working the punch list.*
+
+**Status: all fourteen findings closed, 2026-08-03.** A1 ruled (virtual tick) and applied
+to §16.4/§17.1/§18.4 and items 0.8/2.1. B1 verified (no DTB access; fixed into 0.3/0.6),
+B2 verified (no FP restriction on any arch; fixed into 0.2/0.5), B3 applied (EL governs
+the vector path; 0.4/0.5). C1–C7 applied to their items; D1–D3 swept. The findings below
+are preserved as the record of what was found and why.
 
 #### GAP-A1 — §16.4's central inference is unsound. ~~NEEDS RULING~~ **RULED 2026-08-03: virtual tick.**