FABRIC-3.md §XXXV: bump ratified artemis.img target from 256 MiB to 1 GiB

Captain Bob asked for extra safety margin over the earlier 256 MiB
recommendation. Updated every reference in §XXXV.2/.4/.6 consistently.
Still decision only -- no image built yet.

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

FABRIC-3.md

@@ -5341,9 +5341,9 @@ current 30 MiB image is short of one single trial's worth (516 MB / 8 ≈ 64.5 M
 than 2x. **This has to be fixed before any writer design matters**, and it is a two-part fix, not
 one:
 
-1. **Grow `disk/artemis.img` itself.** Recommend resizing to **256 MiB** -- a real SSD/USB drive
+1. **Grow `disk/artemis.img` itself.** Recommend resizing to **1 GiB** -- a real SSD/USB drive
    on actual bare-metal hardware will dwarf this trivially, so there is no reason to size the dev
-   image tightly; 256 MiB gives comfortable headroom over the summary-only budget computed below
+   image tightly; 1 GiB gives comfortable headroom over the summary-only budget computed below
    (§XXXV.4) even before any tick-sampling extension, without gambling on a number that turns out
    short mid-campaign. **Not done yet -- flagging the concrete risk found while scoping this,
    not fixing it, per this session's own instruction not to apply unrequested fixes:** growing the
@@ -5356,9 +5356,9 @@ one:
    already-minted thumbdrive identities and everything else live on this image
    (`project_thumbdrive_identities_minted_20260906.md`). Two real options, genuinely open, not
    decided here: (a) write a proper migration -- read the fence's live content at the current
-   30 MiB geometry, then rewrite it at the correct offsets for the new 256 MiB geometry, before
+   30 MiB geometry, then rewrite it at the correct offsets for the new 1 GiB geometry, before
    ever letting anything else touch the grown file; or (b) accept identity loss and re-mint fresh
-   on a newly-created blank 256 MiB image, since this is presently a dev/QEMU test artifact, not
+   on a newly-created blank 1 GiB image, since this is presently a dev/QEMU test artifact, not
    a production one -- Captain Bob's call, not assumed here either way.
 2. **Confirm `disk/artemis.img` is genuinely shared across all three ISAs' sequential QEMU
    invocations** (same `$(ARTDISK)` path referenced identically for the amd64/aarch64/riscv64
@@ -5407,7 +5407,7 @@ base, living in the same top-of-device system-metadata fence Zuse's genesis mark
 
 ### XXXV.4 -- What actually gets persisted: trial summaries, not a raw tick mirror
 
-Given the 30 MiB (soon 256 MiB) device is 2-3 orders of magnitude smaller than raw per-tick data
+Given the 30 MiB (soon 1 GiB) device is 2-3 orders of magnitude smaller than raw per-tick data
 at any realistic campaign size, raw per-tick mirroring to block storage is ruled out entirely, not
 just decimated:
 
@@ -5416,13 +5416,13 @@ just decimated:
   of trial-end aggregate physics reads already available at that point (e.g. final
   `fleet_k_q48`/`fleet_conserved`, cumulative `switch_count`). At 18 trials/ISA x 3 ISAs = 54
   records total, this is trivially small (well under 1 MiB even generously sized per record) --
-  no tuning, no risk of overrunning even the current 30 MiB device, let alone 256 MiB. This alone
+  no tuning, no risk of overrunning even the current 30 MiB device, let alone 1 GiB. This alone
   is enough to reconstruct the whole campaign's pass/fail and top-line physics-conservation
   picture with zero dependency on any live serial capture.
 - **v2, optional, explicitly deferred:** decimated sub-trial sampling (e.g. one row every N
   heartbeat ticks instead of every tick) for anyone who wants intra-trial resolution later. Sized
   against whatever's left of the device budget after v1 and whatever migration/resize path
-  (§XXXV.2) is chosen -- rough order of magnitude, at 256 MiB total and reserving generous
+  (§XXXV.2) is chosen -- rough order of magnitude, at 1 GiB total and reserving generous
   headroom for existing fence consumers, a decimation factor in the range of several dozen ticks
   per sample would be needed to fit an 18-trial/ISA x 3-ISA campaign at anything like the
   §XXXIV.5-measured per-trial tick volume; **not sized precisely here, left for whoever
@@ -5444,10 +5444,10 @@ leaving more margin against both unknowns landing on the expensive side at once.
 available as a documented follow-up top-up pass later if N=2's data looks clean and time allows,
 rather than committing to the larger N up front.
 
-### XXXV.6 -- Drive-resize path RATIFIED: fresh 256 MiB image, full re-mint, no migration
+### XXXV.6 -- Drive-resize path RATIFIED: fresh 1 GiB image, full re-mint, no migration
 attempted (2026-09-17)
 
-Captain Bob resolved §XXXV.2's option (a)-vs-(b) fork directly: **build a brand-new 256 MiB
+Captain Bob resolved §XXXV.2's option (a)-vs-(b) fork directly: **build a brand-new 1 GiB
 `disk/artemis.img` rather than migrate the existing 30 MiB one**, on the reasoning that
 re-minting will invalidate the existing identities regardless of whether a fence migration is
 attempted -- i.e. option (a)'s extra complexity (careful top-of-device fence migration to
@@ -5460,7 +5460,7 @@ over even if the bytes were migrated correctly, since the signing material itsel
 device it was minted on.
 
 **Ratified shape:**
-- Build a **new, blank 256 MiB `disk/artemis.img`** from scratch -- not a resize of the current
+- Build a **new, blank 1 GiB `disk/artemis.img`** from scratch -- not a resize of the current
   file. No migration code written or needed.
 - **Zuse re-minted fresh** on the new image (genesis marker, root CA placement, per
   `docs/03-architecture/word-acl/DESIGN.md`'s Phase 8 design and
@@ -5482,7 +5482,7 @@ device it was minted on.
   applies either way.
 - Disposal of the two stale partial amd64 runs' data (§XXXIV.5's own still-open item) is unrelated
   to this pivot and remains undecided.
-- Whether the old 30 MiB `disk/artemis.img` gets deleted/archived once the new 256 MiB image is
+- Whether the old 30 MiB `disk/artemis.img` gets deleted/archived once the new 1 GiB image is
   confirmed live (§XXXV.6).
 - **Nothing built yet** -- this section (including §XXXV.6's ratified drive-resize decision) is
   design/decision only, no capsule/C code, no new disk image, and no re-mint actually performed