feat(account): let an account root live in hardware (P-256), end to end

[xilosada]

Summary

An account is born Ed25519 from its recovery phrase and can now hand its root off to a P-256 key: the only type a secure element (Apple Secure Enclave, Android StrongBox/TEE, TPM) or a YubiKey PIV slot holds. The root only certifies devices; device keys stay Ed25519, so nothing about how ops verify changes.

Before this, a device whose certificate was signed by such a root was refused at join on every peer, even though the credential verifies.

What changed

Commit	Change
feat(account)	RootKeyHandoff.new_root_sign_pk is a tagged RootPublicKey (Ed25519 variant 0, P256 variant 1, SEC1 compressed). Root verification dispatches on the tag; P-256 uses verify_prehash over the 32-byte domain_hash digest. The genesis stays Ed25519, so no AccountId changes. Signed-op schema versions bump (group 11 → 12, namespace 8 → 9), since handoffs ride inside AccountKeysRotated, AccountDeviceLinked and every join credential; the AccountKeysRotated golden bytes gain the tag byte.
fix(governance-store)	GroupAccountKeyValue.root_pk becomes RootPublicKey. apply_rotation no longer bails on a non-Ed25519 handoff: it stores the key the handoff names and verifies the next handoff with the stored key's own algorithm.
docs(account)	AGENTS.md gains RootPublicKey / RootKeyError and the invariant that only the root is tagged.
fix(server)	seal_to_account (#3918) seals to the root's X25519 form, which only an Ed25519 root has. A P-256 root is now refused with a typed error answered as 422, reachable only after both membership gates.

Proof

Reproduction. crates/governance-store: a_device_certified_by_a_p256_root_is_admitted. An account born Ed25519 hands off to a P-256 root, which certifies an ordinary Ed25519 device; the test first asserts verify_device_cert accepts the credential, then that the group admits it.

Before:

test account_bindings::tests::a_device_certified_by_a_p256_root_is_admitted ... FAILED
panicked at crates/governance-store/src/account_bindings.rs:1396:14:
store: cannot persist a p256 root key: the account-key row is a fixed 32 bytes and has no schema version (design risk R2)

After: passes. The 26 existing Ed25519 rotation tests pass unchanged.

Real nodes, real hardware root. Two fresh merod nodes built from this branch:

1. Node A: ordinary merod init, installs an app, creates a namespace, invites.
2. Node B: merod init --no-account-root --account-root <genesis> — an ordinary Ed25519 device key.
3. The account root, rotated into the macOS Secure Enclave, signs node B's DeviceCert (Touch ID) as an AccountProof { genesis, chain: [Ed25519 → P-256], statement }.
4. merod account import-cert verifies and stores it; B joins with meroctl namespace join.
5. Node A, GET /admin-api/groups/<namespace>/member-devices:

   account 363924edd577bf1cbb1dbd0cf9ce4f77e845d4cef812927d848992233095ba67
     device 75517d47eec11210a87c6cb0c4fd5aa90cf571ef94ca81b69e34c3ad1452cff9
   

   No BindingRejected, CredentialInvalid or R2 refusal in either node's log.

Seal. a_member_whose_root_is_p256_is_refused_rather_than_sealed_to beside the four existing seal_to_account tests, which pass unchanged.

CI, locally. ./scripts/check-like-ci.py: 14/14 passed (fmt, clippy -D warnings incl. mock-attestation, full cargo test, store all-features, scenario coverage, deny, machete) on the rebased branch.

Risks and limits

• Flag day. A RootKeyHandoff grows one byte (the tag) and its signing preimage hashes the tagged key; the byte-pinned HANDOFF fixture is regenerated. Both signed-op schema versions are bumped, so every op id changes and old and new nodes reject each other's ops rather than mis-decoding them: every node re-bootstraps. merobox E2E cannot catch mixed versions (same build everywhere).
• Store-row encoding changes, with no schema version. GroupAccountKeyValue no longer decodes rows written before this change. Assumes fresh nodes; there is no migration.
• Handoff-candidate map (projection) is untouched. Keying it on the signature is what stops a forged handoff displacing the real one; with a randomized signer (ECDSA), re-signing the same handoff yields a second entry. Plain re-gossip carries identical bytes and is unaffected.
• Sealing to a P-256 root is refused, not supported. That needs P-256 ECIES.

Not in this PR

• P-256 device keys (a DeviceCert naming a hardware or passkey device key).
• Encrypting the node store with a hardware-sealed key.
• Tooling to sign a hardware-root credential: the PoC used a standalone tool outside the repo; merod account sign-cert still signs at epoch 0 with an empty chain.

[github-actions]

E2E Rust Apps Failed

One or more E2E workflows (scaffolding-e2e, xcall-example) failed.

Please check the workflow logs for more details.