fix(matrix): read MATRIX_RECOVERY_KEY from the active profile secret scope (#69090)

[PRATHAMESH75]

Problem

In a multiplexed gateway (gateway.multiplex_profiles = true), sending an encrypted Matrix message through a secondary profile fails E2EE cross-signing with:

Matrix: recovery key verification failed: Key MAC does not match

Direct API sends and hermes -p <profile> send work; only the multiplexed gateway path is affected. Fixes #69090.

Root cause

Each profile's Matrix adapter is connected inside _profile_runtime_scope (gateway/run.py:9532), which installs that profile's .env as the active secret scope so get_secret(...) resolves the routed profile's credentials. The adapter already threads the per-profile access token and homeserver through its config object, but the E2EE cross-signing bootstrap read the recovery key straight from the process environment:

recovery_key = os.getenv("MATRIX_RECOVERY_KEY", "").strip()

os.getenv ignores the profile scope, so every secondary profile verified cross-signing with the default profile's recovery key — hence the MAC mismatch.

Fix

Resolve the recovery key via get_secret, the same profile-scope-aware primitive the Slack adapter already uses:

recovery_key = (get_secret("MATRIX_RECOVERY_KEY", "") or "").strip()

get_secret reads the active profile's secret scope when one is installed (the multiplexed connect path) and falls back to os.environ when none is — so single-profile gateways are behavior-identical to the old os.getenv. The read sits inside connect()'s existing try/except, so an unscoped multiplex read (fail-closed UnscopedSecretError) degrades to "E2EE bootstrap skipped" rather than crashing.

Scope note

I intentionally left the recovery_key_configured read in get_diagnostics() (adapter.py:1740) on os.getenv. That is a non-authoritative diagnostic boolean, and get_diagnostics has no gateway caller that guarantees it runs inside a profile scope — switching it to get_secret would risk a fail-closed raise on an unscoped status read for no correctness benefit. The reported failure is entirely the connect-time verification path fixed above.

Test

tests/gateway/test_matrix.py::TestMatrixAccessTokenAuth::test_connect_reads_recovery_key_from_active_profile_scope drives the real connect() E2EE path with a secret scope holding the profile's key while os.environ holds a different (default-profile) key, and asserts OlmMachine.verify_with_recovery_key is awaited with the scoped key. It fails against the old os.getenv line and passes with the fix.

252 passed  (tests/gateway/test_matrix.py)
13 passed   (tests/agent/test_secret_scope.py)

The arm64 fork-Docker job is expected to fail on fork PRs and is unrelated to this change.

[alt-glitch]

This was generated by AI during triage.
Duplicate of #69110: both route MATRIX_RECOVERY_KEY through profile-aware secret resolution for multiplexed Matrix E2EE. #69110 is the focused implementation; this head additionally includes an accidental adapter.py.bak copy.

[PRATHAMESH75]

Closing in favor of #69110 by @sergioperezcheco, which was opened first and is the more complete fix for the same bug (#69090):

• fix(matrix): honor profile secret scope for recovery key under multiplex #69110 covers the sibling path too — it routes both connect() and get_diagnostics()'s recovery_key_configured through the scoped read, whereas this PR only fixed connect() and left the diagnostics read on raw os.getenv.
• It handles the unscoped case explicitly — UnscopedSecretError falls back to os.environ for the default-profile startup loop, mirroring the Slack app-token pattern (Multiplex: Slack adapter reads SLACK_APP_TOKEN from process env — all profiles connect Socket Mode to the default profile's Slack app #59739).
• This branch also accidentally committed a stray plugins/platforms/matrix/adapter.py.bak.

No reason to keep a narrower, partly-overlapping duplicate open. Full credit to @sergioperezcheco for #69110.