E2EE: no interactive device verification (SAS / m.key.verification.*)

[TroyHernandez]

Problem

mx.crypto has the olm/megolm primitives and signature checks (mxc_verify_device_keys, mxc_ed25519_verify) and mx.client orchestrates encrypt/decrypt (mx_crypto_*), but there is no interactive device verification flow:

• No handling of m.key.verification.request / .start / .accept / .key / .mac / .done to-device events
• No SAS (emoji/decimal) computation
• No cross-signing support (master/self-signing/user-signing keys, m.cross_signing.*)

Practical consequence: bot devices show as unverified (red shield) in Element, and a user cannot complete verification with a bot for a fully trusted encrypted room. Surfaced 2026-07-12 when @troy tried to verify @cornelius for encrypted chat.

Proposal (increments)

1. Minimum: respond to m.key.verification.request with SAS flow (m.sas.v1), auto-accept, compute + surface emoji so the human can confirm on their side; complete .mac/.done. Handles the Element red-shield case.
2. Cross-signing: generate/publish cross-signing keys at login, sign own device, verify other users via their master key.
3. Corteza hook so a verification request in a room/DM pings the bot loop and completes without manual intervention.

References

• Spec: https://spec.matrix.org/latest/client-server-api/#device-verification
• Related: room creation gap (#see other issue) — same class of "client can converse but not manage" limitations.