[Feature]: Add Element-specific compatibility to Matrix channel — recovery-key device verification and MAS next-gen OIDC (MSC2965) login

## Summary

Element is now the de-facto reference client — and effectively the main maintainer — of the Matrix ecosystem. QwenPaw's Matrix channel, built on matrix-nio, currently lacks Element-specific compatibility: it only supports legacy login (password / compatibility-session token) and cannot participate cleanly in the verification flow Element uses. I'd like to request Element-specific support: (1) the ability to complete device verification by entering a recovery key, and (2) support for the new Matrix Authentication Service (MAS) next-gen OIDC (MSC2965) flow instead of only legacy compatibility sessions.

## Component(s) Affected

- [ ] Core / Backend (app, agents, config, providers, utils, local_models)
- [ ] Console (frontend web UI)
- [x] Channels (DingTalk, Feishu, QQ, Discord, iMessage, etc.)
- [ ] Skills
- [ ] CLI
- [ ] Documentation (website)
- [ ] Tests
- [ ] CI/CD
- [ ] Scripts / Deploy

## Problem / Motivation

Element (Web/Desktop/X) is the mainstream Matrix client and its development is now largely driven by Element (e.g. the reference homeserver Synapse moved to element-hq). This means the practical user experience of Matrix is defined by Element's behavior. Two places where a QwenPaw bot hits friction against Element:

1. **Verification / "unverified device" warnings.** Because Element enables end-to-end encryption by default in new rooms, a QwenPaw bot that joins as another device of a user account needs to be verified to avoid persistent "unverified device / unencrypted" warnings in Element. But QwenPaw (via matrix-nio) has **no cross-signing support**, so the human-friendly path Element offers — completing verification by entering a **recovery key** — is impossible. The bot also auto-accepts and auto-confirms SAS, which can leave the Element side stuck or cancelled with `key mismatch`.

2. **No MAS / next-gen OIDC support.** Element is steering the ecosystem toward next-gen authentication via the Matrix Authentication Service (MAS) and OIDC (MSC2965). QwenPaw's Matrix channel only supports legacy logins (password or a compatibility-session access token), so it cannot log in through the modern MAS OIDC flow that Element clients use.

## Proposed Solution

Add Element-specific compatibility to the Matrix channel:

1. **Recovery-key verification** — allow a QwenPaw device to be verified by supplying the recovery key (cross-signing / secret-storage), so Element stops showing "unverified device" warnings without requiring a human to compare emoji with a headless bot.
2. **MAS / next-gen OIDC (MSC2965) support** — allow logging in via the MAS OIDC flow (discover `org.matrix.msc2965.authentication`, OIDC token exchange) instead of only legacy compatibility sessions.

If matrix-nio itself needs OIDC/cross-signing support first, please call that out upstream (and/or evaluate an alternative client/SDK that provides these primitives).

## Alternatives Considered

- **Use an unencrypted room** — works today but defeats E2EE and leaves the "unverified" friction unresolved for encrypted deployments.
- **Manual emoji comparison** — not feasible for a headless bot with no UI.
- **Switch to a different Matrix SDK** that supports cross-signing and OIDC — higher migration cost, but worth evaluating if matrix-nio cannot provide the needed primitives.

## Additional Context

- QwenPaw Matrix channel implementation: `qwenpaw/app/channels/matrix/channel.py` (auto-accept / auto-confirm verification logic).
- Underlying library: `matrix-nio` (Python SDK) + `vodozemac`.
- Matrix Authentication Service (MAS): https://element-hq.github.io/matrix-authentication-service/ — next-gen auth (OIDC / MSC2965) vs. legacy compatibility sessions.
- Cross-signing spec: https://spec.matrix.org/latest/client-server-api/#cross-signing.

## Willing to Contribute

- [ ] I am willing to open a PR for this feature (after discussion).