Re-mint bob with the restricted personality, closing out the identity set (FABRIC-3.md §XI.6)

bob-thumb-ident.img predated MINT_PERSONALITY_STD79_LOCKDOWN (minted
2026-09-06, f4ded3e landed 2026-09-07) -- the one identity §XI.4's
00-06 conversion missed. Zeroed its homeblocks_sig_t signature block
and re-minted with the same real identity data it originally had
(full_name="Captain Bob", username="rajames",
email="rajames440@gmail.com"), this time with the restricted
personality flag.

Verified standalone (no Zuse, fresh boot): fast attach as "rajames",
USE, standard words computing correctly (11, 49), and VM-EXEC
(ACL-denied) recovering gracefully without halting -- exercising both
the §XI.4 fault-scoping fix and the §XI.5 xHCI/WIREBIND fixes live.

All 9 thumbdrives (zuse, bob/rajames, 00-06) now carry real,
MINT-verified identities; all 8 non-Zuse ones carry the restricted
FORTH-79/83 personality.

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

FABRIC-3.md

@@ -1986,3 +1986,52 @@ device failed" anywhere, and the console was immediately `USE`-able and fully in
 `02` (arithmetic computed correctly, `VM-EXEC` denial recovered gracefully per §XI.4's fix,
 console stayed responsive). Three-arch `clean qemu` acceptance (amd64/aarch64/riscv64) passed,
 all three clean on the first attempt.
+
+### XI.6 — `bob` re-minted with the restricted personality, closing out the identity set
+
+§XI.4 converted `00`–`06` to the same `MINT_PERSONALITY_STD79_LOCKDOWN` restricted personality
+(§IX/`f4ded3e`); `bob-thumb-ident.img` was the one identity left over from before that mechanism
+existed (minted 2026-09-06, `f4ded3e` landed 2026-09-07 -- see
+`project_thumbdrive_identities_minted_20260906.md`), so it was still carrying the original,
+unrestricted personality. `zuse-thumb-ident.img` is deliberately excluded from this -- she is the
+superuser identity, not a restricted test identity, and her personality is not in scope for this
+conversion.
+
+**Workflow (identical to §XI.4's, same real data `bob` originally minted with, not placeholder
+data):**
+1. Backed up `disk/thumbdrives/bob-thumb-ident.img` to the session scratchpad
+   (`thumbdrive_backups/bob-thumb-ident.img.bak`) before touching it.
+2. Zeroed just its `homeblocks_sig_t` signature block (devblock 1, byte offset 4096, 4096 bytes:
+   `dd if=/dev/zero ... bs=4096 seek=1 count=1 conv=notrunc`) -- invalidates recognition without
+   touching the rest of the drive, the same non-destructive re-mint precondition §XI.4 used.
+3. Booted amd64 with Zuse attached (`MINT` needs her live private seed -- §XI.3's Bug 2 fix
+   changed only *verification*, not *minting*, which still genuinely requires her live session).
+4. Hotplugged `bob-thumb-ident.img` on xHCI port 2 via QMP, confirmed fast attach
+   (`blkio_usb: MSC device ready`).
+5. `S" Captain Bob" S" rajames" S" rajames440@gmail.com" S" " -1 MINT` over the serial socket --
+   the exact same identity data (`full_name`, `username`, `email`, empty `phone`) `bob` was
+   originally minted with, this time with the trailing `-1` selecting the restricted personality.
+   Confirmed via `MINT: identity minted`.
+
+**Verified standalone, amd64 (no Zuse this boot, fresh boot, exercising both §XI.4's fault-
+scoping fix and §XI.5's port-reuse fix in the process since they're now load-bearing for every
+identity attach):**
+- Fast attach: `WIREBIND: rajames attached and ready -- USE it to begin` (registry name is the
+  bare `username`, `rajames`, matching every other identity's own naming convention -- `bob` was
+  always a nickname for this identity in conversation, never the actual on-disk/registry name).
+- `S" rajames" USE` switched the console onto it correctly.
+- Standard words computed correctly: `5 6 + .` -> `11`, `7 7 * .` -> `49`.
+- `VM-EXEC` (ACL-denied under the restricted personality, same as every other identity) recovered
+  gracefully -- printed `VM-EXEC: ERROR in rajames~user` (captured in the log as
+  `rajaames~user`, one duplicated character; every other character and both computed results came
+  through correctly, and the session recovered and kept computing correctly afterward -- read as
+  a VT100/cursor-blink console rendering artifact rather than a real string-construction bug,
+  consistent with this project's own prior terminal-rendering defect history (§I.9), not chased
+  further since it didn't affect functional behavior). No halt, console stayed fully interactive.
+
+**Result:** all 9 thumbdrives (`zuse`, `bob`/`rajames`, `00`–`06`) now carry a real, MINT-verified
+identity; every non-Zuse one (`bob`/`rajames` plus `00`–`06`, 8 total) carries the restricted
+FORTH-79/83 personality and has been individually verified standalone. Not re-run as a fresh
+3-arch acceptance pass on its own -- this is a data-only change to one thumbdrive image, no
+kernel/capsule code touched, and amd64's own live verification above already exercises the same
+code paths (§XI.4/§XI.5) the last 3-arch pass (§XI.5, commit `b301317`) already accepted.