FABRIC-2.md: drop GPT partitioning for home-blocks USB drive, whole-device layout instead

Checked the math with Captain Bob: a PBAM for ~15GB of user blocks needs
only ~1.92MB (15M blocks / 32768 per 4KB page), fitting easily alongside
identity/credential/PKI material in a 1GB reserved region. No partition
table needed -- same whole-device pattern artemis.img already uses today,
just with a generously fixed ~1GB reserved region instead of tight
bam_start+bam_devblocks packing. Eliminates the GPT-parser work item
entirely (no GPT code exists in src/starkernel/ today). Confirmed no
conflict with Milestone 8's USB boot drive, which is a separate physical
drive (flashed starkernel.iso) with its own independent GPT/ESP need.

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

FABRIC-2.md

@@ -3980,23 +3980,40 @@ Depends on Milestone 2 existing (needs a real device to test against, though the
 identity→range derivation logic itself could be unit-tested against the existing RAM/
 RAMDRIVE/DISK devices first without waiting for USB).
 
-**Decided with Captain Bob, 2026-08-22 — USB thumb drives get GPT-partitioned, unlike
+**Superseded 2026-08-25 — GPT partitioning dropped, whole-device layout instead (same
+pattern `artemis.img` already uses).** The 2026-08-22 decision below (kept struck-through for
+history) called for a GPT-partitioned drive; revisited when the math was actually checked.
+Reference/target physical drive size: **16GB**. A straight bitmap PBAM (`blk_volume_meta_t`'s
+existing format, 32768 blocks tracked per 4KB page) for ~15GB of user blocks needs only
+~1.92MB (15M blocks ÷ 32768 × 4KB) — comfortably inside a 1GB reserved region alongside
+whatever the identity/credential/PKI material (Section U/V's PKI work, not yet designed in
+detail) turns out to need, with ~998MB headroom to spare. So: **no partition table at all** —
+the whole drive is one `blk_dev_slot_t`-style device, header at devblock 0, exactly like
+`artemis.img` today, just with the reserved region sized to a generous fixed ~1GB (header +
+PBAM + identity material) instead of the tight `bam_start + bam_devblocks` packing the current
+format computes on the fly. Everything after that reserved region is the user-visible
+block-storage LBN range, attached via `blk_subsys_attach_device()` the normal way (matching
+Artemis's own precedent exactly, not a new mechanism). **This eliminates the GPT-parser work
+item below entirely** — no GPT read/write code needs to exist in `src/starkernel/` at all for
+this drive. Checked for conflicts: Milestone 8's USB drive (bare-metal boot demo) is a
+*different* physical drive — a flashed `starkernel.iso` boot stick — not the home-blocks
+identity drive, so dropping GPT here doesn't touch that milestone's own (separate, UEFI-driven)
+GPT/ESP requirement. `disk/usb-thumbdrive-test.img` stays a small 64MB test fixture regardless
+— a 16GB file isn't practical to commit to this repo; 16GB is the real-world design target the
+*layout math* is sized around, not the size of every test image.
+
+~~Decided with Captain Bob, 2026-08-22 — USB thumb drives get GPT-partitioned, unlike
 `artemis.img`'s current whole-device STFR/v2 header (`blk_compute_fresh_geometry()`,
 `src/block_subsystem.c:405-429` — that layout writes the header directly at devblock 0 of the
-whole device, no partition table).** Reference/target physical drive size: **16GB**. Layout:
-one GPT partition ≈1GB for LithosAnanke metadata (identity/credential/ACL material — Section
-U/V's PKI work, not yet designed in detail), remainder (≈15GB) as a second partition holding
-the block-storage region that gets attached into the LBN chain via `blk_subsys_attach_device()`
-(pointed at that partition's start LBA, not devblock 0 of the raw device). Sizing explicitly
-tentative — "we'll figure it out" if 1GB proves too small once the metadata format is designed.
-**Not yet a punch-list item, and not yet built: this repo has no GPT parser anywhere in kernel
-code today** (the riscv64 boot disk's GPT layout, `Makefile.starkernel`'s `sgdisk` call, is
-host-side build tooling for the UEFI ESP, not kernel-read code) — reading/writing a real GPT
-partition table from `src/starkernel/` is new, unstarted work this decision now requires,
-before `blkio_usb.c` can hand `blk_subsys_attach_device()` a correctly-offset device view.
-`disk/usb-thumbdrive-test.img` stays a small 64MB test fixture regardless — a 16GB file isn't
-practical to commit to this repo; 16GB is the real-world design target the *layout math* is
-sized around, not the size of every test image.
+whole device, no partition table). Layout: one GPT partition ≈1GB for LithosAnanke metadata,
+remainder (≈15GB) as a second partition holding the block-storage region that gets attached
+into the LBN chain via `blk_subsys_attach_device()` (pointed at that partition's start LBA, not
+devblock 0 of the raw device). Not yet a punch-list item, and not yet built: this repo has no
+GPT parser anywhere in kernel code today (the riscv64 boot disk's GPT layout,
+`Makefile.starkernel`'s `sgdisk` call, is host-side build tooling for the UEFI ESP, not
+kernel-read code) — reading/writing a real GPT partition table from `src/starkernel/` was new,
+unstarted work this decision required, before `blkio_usb.c` could hand
+`blk_subsys_attach_device()` a correctly-offset device view.~~
 
 - [ ] Design the identity→block-range derivation function's exact input/output (Section V
       area A open point: currently zero decisions made, not even a function signature)