FABRIC.md: resolve item 1.6 -- a VM's mass is its allocated share

Punch list §25 item 1.6 complete.
Confirms §20.4's proposal as decided: mass = the quota Hera allocated,
not a fixed one-cell footprint. Already implied by §22's elasticity
mechanism and §24.3, and already assumed by items 1.2-1.5 -- this
closes the formal "proposal" flag to match.

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

FABRIC.md

@@ -1418,10 +1418,22 @@ built, or to collapse it into a single region and discard the level that works.
 ~~**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
+### 20.4 A VM's mass is the capacity share Hera allocated it — RESOLVED by item 1.6
 
-Marked as proposal, not finding: `VMPhysics` currently holds only `execution_heat_q48`,
-`last_active_ns` and `is_live` (`capsule_vm_physics.c:59-63`). There is no share field.
+**RESOLVED 2026-08-04.** What follows was written as a proposal; it is confirmed here rather
+than rewritten, because everything since has already been treating it as decided. §22's
+elasticity mechanism (DECIDED) only means something if a VM's mass is its variable quota —
+"capacity flows down the density gradient" (§22.1) is vacuous if every VM's mass were pinned
+at one cell. §24.3 already states outright that "a VM's mass is elastic by §22." Items 1.2
+through 1.5 (the resting floor, the transfer trigger, the timescale ratio, the outer bound)
+all already read mass-as-quota as given. §20.5 #2's own framing settles it independently:
+the one-cell alternative "throws away the distinction" in the table below, which is the
+entire reason for doing this. **A VM's mass is the capacity share — the quota — Hera
+allocated it**, not a fixed one-cell footprint regardless of size.
+
+Decided on paper, not yet built: `VMPhysics` currently holds only `execution_heat_q48`,
+`last_active_ns` and `is_live` (`capsule_vm_physics.c:59-63`). There is no share field yet —
+adding one is implementation work for a later phase, not this item.
 
 §7 says Hera's job is Stadium distribution, and that *allocating a VM's share is birthing
 it*. If that share is the VM's mass, §19's density definition applies unchanged at the
@@ -1476,9 +1488,8 @@ decides where work goes; that remains capability-based routing.
    same stroke. The outer total does not itself flex at runtime; only per-VM quotas do
    (§22). An outer bound that could grow or shrink live would mean §2's "inescapable wall"
    is not actually inescapable.
-2. **Is a VM's mass its allocated share, or one cell?** §20.4 proposes the share. The
-   alternative — every VM is one entry regardless of size — is simpler but throws away the
-   distinction in the table above, which is the reason to do this at all.
+2. ~~**Is a VM's mass its allocated share, or one cell?**~~ **RESOLVED by item 1.6 — the
+   allocated share.** See §20.4.
 3. ~~**What is Hera's own mass?**~~ **RESOLVED — Hera is pinned, and her eviction is a
    panic.**
 
@@ -2382,7 +2393,13 @@ document and committing that amendment as its own item.*
   > §20.2's cold-start birth rule (a newborn can never out-density an existing warm VM).
   > Making room stays Hera's own deliberate act. Full argument in §20.5 #1.
 
-- [ ] **1.6 — A VM's mass: allocated share, or one cell.** *Refs:* §20.4, §20.5 #2.
+- [x] **1.6 — A VM's mass: allocated share, or one cell.** *Refs:* §20.4, §20.5 #2.
+
+  > **RESOLVED 2026-08-04 — allocated share.** Less a fresh choice than a confirmation of
+  > what §22's elasticity mechanism and §24.3 already treated as decided, and what items
+  > 1.2–1.5 already assumed. The one-cell alternative would make outer-level density
+  > collapse to heat alone, discarding the starved-vs-small diagnostic that's the entire
+  > point of §20.4. Full argument in §20.4.
 
 - [ ] **1.7 — Rule out recursion beyond two levels** — deliberately, not by omission.
   *Refs:* §20.5 #4.