FABRIC-3.7.md: settle drive-cloning defense as rejected, not undesigned

Captain Bob rejected a PIN/passphrase second factor firmly and directly
after it was built and live-tested on all three architectures: "nothing
like a pin or a password or secret code or any bullshit... Everybody has
secrets. There's only the drive." All PIN-related code (KDF, XOR
keystream seed encryption, no-echo input, MINT/WIREBIND prompts,
user_identity_seed_t v3 format) was reverted before commit -- none of it
ever landed in git history.

This project's identity model has no knowledge factor, by design:
physical possession of the thumbdrive is the entire credential. A
byte-for-byte clone being equivalent to the real drive is the accepted
model, not a gap needing a fix. Recorded here so future work doesn't
default back to a PIN/password approach.

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

FABRIC-3.7.md

@@ -171,17 +171,20 @@ Corrected per §2's re-read above. Concretely, when Phase 8 next picks this up:
   2026-09-22) — `ZUSE-ELIGIBILITY-ADD` denied by default, granted only inside `ACL-ZUSE-BOOT`'s
   authenticated branch. This closes the actual "grant yourself eligibility with no real drive at
   all" path — a real, independently-confirmed gap, unaffected by this correction.
-- The Ed25519 **challenge-response** itself — proving the caller holds the *private* key, not
-  just presenting a pubkey that matches something in `zuse_eligibility_is_member()`'s list — is
-  a separate, larger piece of this same Phase 8 item and is not designed here. Today, WIREBIND/
-  MINT trust whatever identity is stored on an attached thumbdrive with no challenge at all
-  (confirmed by grep: no `ed25519_sign`/`ed25519_verify` call anywhere in `capsule_wirebind.c` or
-  `capsule_mint.c`). Also confirmed this session: the private key seed itself is stored in
-  plaintext on the drive, read in the same devblock as the pubkey/cert — a naive
-  challenge-response wouldn't defend against a cloned drive, since the clone has the seed too.
-  Defending against drive cloning (as opposed to "no real drive at all," which the cert-signature
-  chain already defends against) is a separate, harder, undesigned problem — see the Phase 8 v1
-  plan (`/home/rajames/.claude/plans/jiggly-cuddling-stallman.md`) for the full reasoning.
+- **Defending against a cloned drive — settled, 2026-09-23: not going to happen, by design.**
+  Today, WIREBIND/MINT trust whatever identity is stored on an attached thumbdrive with no
+  challenge at all (confirmed by grep: no `ed25519_sign`/`ed25519_verify` call anywhere in
+  `capsule_wirebind.c` or `capsule_mint.c`), and the private key seed itself is stored in
+  plaintext on the drive, read in the same devblock as the pubkey/cert. **This is accepted, not
+  a gap.** Captain Bob, directly: *"nothing like a pin or a password or secret code or any
+  bullshit... Everybody has secrets. There's only the drive."* Physical possession of the drive
+  is the entire, deliberate credential model — a byte-for-byte clone being equivalent to the
+  real drive is the accepted design, not a defect to close. A PIN/passphrase second factor was
+  built, live-tested on all three architectures, and fully reverted before commit
+  (`/home/rajames/.claude/plans/jiggly-cuddling-stallman.md`, now marked rejected; memory
+  `feedback_no_knowledge_factor_identity`) — **do not revisit a knowledge-factor approach here.**
+  Any future work in this space needs a fundamentally different mechanism (not something typed
+  and known) or stays an accepted limitation.
 
 ## 5. What this document is not