docs: plan cryptographic fresh-user and biometric assurance proofs (coven#815)

[CompleteDotTech]

Summary

• Adds docs/design/mobile-assurance-step-up-v1.md — the concrete plan/spec for issue Plan: cryptographic fresh-user and biometric assurance proofs OpenCoven/coven#815: an independently verifiable COVEN-ASSURANCE/1 step-up proof that lets request authentication satisfy FreshUserVerification/FreshBiometric grant requirements without ever trusting a client-asserted assurance level.
• Today MobileAuthenticator::verify hardcodes AssuranceLevel::Possession when calling DeviceGrant::authorize (crates/coven-cli/src/mobile_memory/auth.rs:149), so assurance requirements are unreachable. The spec introduces a separately enrolled, platform-policy-protected step-up authorization key whose fresh signatures — over canonical bytes binding device, grant, revocation epoch, the exact request or DeviceActionIntent digest, a server-issued single-use challenge, a ≤120 s window, and the requested assurance — are the only way to raise assurance.
• The server computes effective assurance itself (min(claimed, enrolled-class ceiling)) and passes it to DeviceGrant::authorize (grant.rs:157-194); absent/invalid/expired/replayed proofs degrade to possession-only or fail closed per grant policy.
• Includes the pairing-v2 transcript extension that binds the optional step-up key and its declared assurance class into the confirmation phrase before grant issuance, a separate authorization-keys.json store, rotation/revocation semantics that never touch familiar/root identity, iOS (SecAccessControl/LocalAuthentication) and Android (hardware Keystore/BiometricPrompt) mappings, a security-invariant mapping table, a self-verifying synthetic golden vector (hex-encoded, the mobile-pairing-v2 fixture convention), and TypeScript types + JSON Schema for Swift/Android implementers. Every design claim cites the current mobile_memory code path it builds on.

Issue

• Refs Plan: cryptographic fresh-user and biometric assurance proofs OpenCoven/coven#815 (parent tracking: Plan: Device-bound credentials, biometric authorization, and scoped grants OpenCoven/coven#786; builds on feat: add versioned device grants to mobile authority OpenCoven/coven#791 and fix: re-land transcript-bound mobile pairing v2 OpenCoven/coven#812).

Implementation

• Approach: design document only — no code changes. It is the deliverable the issue asks for ("Plan: …"); implementation PRs follow the staged plan in the doc.
• Files changed: docs/design/mobile-assurance-step-up-v1.md (new, alongside mobile-pairing-protocol-v2.md and mobile-device-trust.md).
• User-visible behavior: none yet (docs-only). The document reconciles pairing v2's "biometric authorization is outside this transcript" property with binding the authorization key (an enrollment fact, not biometric data) into the transcript.
• Compatibility: additive — v1 devices and v2 clients without the extension are byte-for-byte unaffected; older hosts reject the optional enrollment member and fail closed by design.

Verification

• python3 scripts/check-secrets.py — equivalent content-level scan executed locally (python3 unavailable in the authoring environment): no secret-rule, generic-assignment, or high-entropy findings in the added file; all synthetic vector values are hex-encoded per the existing mobile-pairing-v2 fixture convention
• python3 scripts/check-coven-privacy.py --staged — equivalent scan of the added file: no Coven-specific identifiers, absolute home paths, or phone/invite-URL patterns
• cargo fmt --check, cargo clippy --workspace --all-targets -- -D warnings, cargo test --workspace --locked — deferred to CI; no Rust sources are added or modified (docs-only change; the changes classifier should mark this PR docs_only and skip the Rust/AFS/npm/engine jobs)
• Document self-checks: all 13 internal anchors resolve; JSON blocks parse; the golden vector re-derives its canonical bytes, Uuid::new_v5 grant id, key id, context digest, and ECDSA P-256 signature from the documented hex values alone; the signature rejects any tampered byte
• Additional manual checks: deconfliction sweep (no open PR or branch for Plan: cryptographic fresh-user and biometric assurance proofs OpenCoven/coven#815 on OpenCoven/coven or CompleteDotTech/coven before starting)

Risk and Rollback

• Risk level: low — additive documentation; no runtime code paths touched.
• Rollback plan: revert the single commit.

Agent Handoff

• Current state: ready for review; draft until CI is green.
• Follow-ups: the staged implementation plan in the doc (assurance.rs canonical bytes + challenge store, pairing extension + authorization-key store, gateway plumbing, golden-vector fixture + conformance test).
• Known gaps: python3 was unavailable locally, so the two policy-guard scripts were emulated at the content level rather than run verbatim; CI runs the real ones.

Vehicle note: opened in the fork CompleteDotTech/coven as the CI vehicle — this token cannot write to OpenCoven/coven. Re-target upstream once write access is restored. Refs OpenCoven#815.