Feature: Recovery key–based crypto bootstrap (alternative to SAS)

[mjkatgithub]

Goal

Users who cannot complete interactive self-verification (SAS/emoji with another client) can still establish trust on this session by entering a valid Matrix recovery / security key (or equivalent secret flow), so Decentra can hydrate cross-signing and decrypt where the homeserver allows.

Scope

• In-app entry point (e.g. Settings → Account or secure onboarding step) for recovery key input; never log the raw key.
• Integrate with matrix-js-sdk Rust crypto + Secret Storage / bootstrap APIs (align with how keys are created at registration today).
• Clear copy: when to use vs. device verification; link or reference existing docs.
• Error handling: wrong key, missing secret storage, UIA-required homeserver paths.
• Optional: rate-limit / lockout messaging for repeated failures (if applicable).

Out of scope (unless split): full account reset, email-based recovery, or server-side key escrow.

Branch

feature/recovery-key-crypto-bootstrap

Acceptance Criteria

• User can submit a recovery key and reach a defined success state (e.g. cross-signing usable for this device, or documented partial success per HS).
• Invalid or rejected keys show actionable i18n messages (EN/DE consistent with useAppI18n).
• No recovery key material in console logs, analytics, or persisted plain text.
• Flow is documented in README or in-app help at a minimal level.

Test Checklist

Unit

• Composable / helper tests for validation and error mapping (mocked crypto).

Integration

• Optional: stubbed Matrix HTTP for secret storage bootstrap if feasible.

E2E

• Optional: Synapse profile with secret storage / recovery path if the stack supports it.

Notes

• Complements device verification (SAS); does not replace it for users with a second trusted client.
• Depends on correct bootstrapCrossSigning / secret storage callbacks and homeserver capabilities; may require UIA on some servers.