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

include/starkernel/capsule_wirebind.h

@@ -122,6 +122,29 @@ void capsule_wirebind_unclean_detach(void);
  */
 const char *capsule_wirebind_attached_username(void);
 
+/**
+ * capsule_wirebind_overflow_idle_check - FABRIC-2.md §I.2's own "overflow
+ * trigger," decided and built 2026-09-05. Called once per idle tick
+ * (sk_repl_idle(), repl.c, alongside blk_migration_idle_check() -- same
+ * ~1 Hz cadence), same as that function's own convention.
+ *
+ * No-op if nothing is attached via WIREBIND. Otherwise reads the attached
+ * drive's own free/total via blk_get_device_free_blocks() (real numbers:
+ * a WIREBIND-attached drive is always HOMEBLOCKS_SIG_OK, i.e. already
+ * STFR/v2-formatted, by the time blk_subsys_attach_device() runs on the
+ * same dev pointer right after WIREBIND itself -- not PROVISIONAL, not
+ * raw). If free space is below a fixed threshold AND the attached
+ * identity does not already own a claim (blk_owner_has_claim() -- a disk
+ * scan, not a RAM flag, so this decision survives reboot/reattach for
+ * free), claims a fixed number of additional devblocks on Artemis's own
+ * device via blk_firsttouch_claim() -- a one-time-per-identity extension,
+ * not a growth loop, deliberately: this does not free space on the
+ * user's own drive, it only extends their pool onto system-resident
+ * space, so re-claiming every tick once already extended would walk
+ * Artemis's device to exhaustion for no benefit.
+ */
+void capsule_wirebind_overflow_idle_check(void);
+
 #endif /* __STARKERNEL__ */
 
 #endif /* STARKERNEL_CAPSULE_WIREBIND_H */