Build the FIRSTTOUCH overflow trigger flagged in FABRIC-2.md §I.2

The overflow-triggered migration path (a WIREBIND-attached identity's own
drive running low on space) was scoped but never built -- only the
trigger-detection call site was missing, per this section's own text.

- capsule_wirebind.c now tracks the attached blkio_dev* alongside the
  already-tracked VM id, set in try_attach() and cleared in both
  EJECT/UNCLEAN paths.
- New capsule_wirebind_overflow_idle_check(), called once per idle tick
  in repl.c right alongside blk_migration_idle_check() (same cadence):
  reads the attached drive's free/total via blk_get_device_free_blocks(),
  and if free space is below a fixed 10% threshold, extends the
  identity's pool with a one-time blk_firsttouch_claim() of 8 additional
  devblocks on Artemis's system-resident device.
- New blk_owner_has_claim(owner_fp) in block_subsystem.c answers the
  debounce question blk_firsttouch_claim()'s own doc comment had left
  open: a disk scan, not a RAM flag, so the already-extended answer
  survives reboot/reattach, matching BMAPFMT's "ownership travels with
  the block" model.

Premise checked before building (does a WIREBIND-attached drive actually
give a real free/total signal, or does it stay PROVISIONAL/raw): traced
repl.c's attach sequence and confirmed blk_subsys_attach_device() runs on
the same dev pointer right after WIREBIND, and a WIREBIND-eligible drive
is always already STFR/v2-formatted, so the signal is real. Premise held,
unlike the BAM item's overstated one.

Verified with the mandatory 3-arch QEMU acceptance (identical dictionary
hashes, no regression) plus a live logic test of blk_owner_has_claim():
a temporary TEST-OWNER-CLAIM word, run once via SK_CMD and reverted,
confirmed it correctly detects the claiming owner and rejects an
unrelated one. The low-disk-space-triggers-a-claim path itself is not
verified end-to-end -- that needs a real minted WIREBIND-user thumbdrive
with deliberately tiny capacity, out of scope for this pass; noted as
such in the FABRIC-2.md §I.2 closure note rather than overclaimed.

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

FABRIC-2.md

@@ -4431,6 +4431,35 @@ stale the way the original carry-forwards did.
   scoped, mirroring `blk_subsys_detach_device()`'s own internal lookup, now exposed) exist
   specifically so that call site is a small addition when someone picks it up, not a redesign.
 
+  **CLOSED 2026-09-05.** Premise checked before building, not trusted from this item's own
+  text (same discipline that caught the BAM item's overstatement): traced `repl.c`'s USB-attach
+  sequence and confirmed `capsule_wirebind_try_attach(&usb_blk_dev, ...)` (the regular-identity
+  WIREBIND path, `HOMEBLOCKS_SIG_OK` only) runs immediately before `blk_subsys_attach_device
+  (&usb_blk_dev)` on the same pointer — since a WIREBIND-eligible drive is already a real
+  STFR/v2-formatted home-blocks drive, `blk_format_or_load_disk()` takes the recognized-header
+  branch, not PROVISIONAL, so `blk_get_device_free_blocks()` returns real numbers by idle-check
+  time. Premise held. **Built**: `capsule_wirebind.c` now tracks the attached `blkio_dev*`
+  (`g_wirebind_attached_dev`, set alongside `g_wirebind_attached_vm_id` in `try_attach()`,
+  cleared in both `EJECT`/`UNCLEAN`); new `capsule_wirebind_overflow_idle_check()`, called once
+  per idle tick in `repl.c` right alongside `blk_migration_idle_check()` (same cadence), reads
+  the attached drive's free/total via `blk_get_device_free_blocks()` and, if free space is
+  below a fixed 10% (`WIREBIND_OVERFLOW_FREE_THRESHOLD_PCT`, "fixed first" per this project's
+  own standing sequencing), extends the identity's pool with a **one-time**
+  `blk_firsttouch_claim()` of 8 additional devblocks (`WIREBIND_OVERFLOW_CLAIM_DEVBLOCKS`) on
+  Artemis's system-resident device. **New `blk_owner_has_claim(owner_fp)`** (`block_subsystem.c`)
+  answers the debounce question this section's own doc comment on `blk_firsttouch_claim()`
+  had left as "a separate, not-yet-decided question" — decided on the reboot-survival axis: a
+  disk scan (same shape as `blk_firsttouch_claim()`'s own scan), not a RAM flag, matching
+  BMAPFMT's "ownership travels with the block, no centralized table" model, so the
+  already-extended answer survives reboot/reattach for free. **Verified**: full 3-arch QEMU
+  acceptance (identical dictionary hashes, no regression) plus a live logic test of
+  `blk_owner_has_claim()` itself — a temporary `TEST-OWNER-CLAIM` word, run once via `SK_CMD`
+  and reverted, confirmed it correctly detects the claiming owner and correctly rejects an
+  unrelated one. **Not verified end-to-end**: the actual low-disk-space-triggers-a-claim path
+  itself, which needs a real minted WIREBIND-user thumbdrive with deliberately tiny capacity to
+  reproduce naturally — out of scope for this pass; the plumbing exercises its no-op branch
+  every idle tick with no crash, but the "drive actually runs low" branch is unexercised.
+
   **Also left open, a real correctness gap, not swept under**: `blk_meta_t`'s `owner_fp`/
   `BLK_FLAG_CLAIMED` (BMAPFMT's distributed ownership) and the pre-existing, separate BAM
   (`blk_bam_entry_t{allocated,dirty}`, the generic free/allocated bitmap `blk_allocate()`/