fix(matrix): resolve crypto store per-instance so multiplexed profiles don't share crypto.db

[mjshorty]

Summary

Fixes #89168 — the Matrix crypto-store collision under the multiplex gateway.

Root cause: plugins/platforms/matrix/adapter.py resolves the crypto store at module scope:

_STORE_DIR = _get_hermes_dir("platforms/matrix/store", "matrix/store")
_CRYPTO_DB_PATH = _STORE_DIR / "crypto.db"

With gateway.multiplex_profiles=true, the multiplexer is a single process that imports this module once; get_hermes_home() at import time resolves to the root ~/.hermes. Every profile's Matrix adapter therefore opens the same crypto.db — all bots' Olm identities collide in one store and inbound E2EE fails with Error decrypting megolm event, no session found.

Fix: replace the module-level constants with per-instance _get_store_path() / _get_store_dir() that resolve through get_hermes_dir() at connect time. Under multiplex, each profile's adapter is created and connected inside _profile_runtime_scope, so the context-local HERMES_HOME override makes every profile resolve its own store dir (<root>/profiles/<name>/platforms/matrix/store/crypto.db).

This mirrors the existing pairing-store migration (a6397c379 — "fix(gateway): align multiplex pairing stores"), which fixed the identical module→per-instance bug for the pairing store.

Changes

• plugins/platforms/matrix/adapter.py
  • Remove module-level _STORE_DIR / _CRYPTO_DB_PATH path resolution.
  • Add MatrixAdapter._get_store_path() (crypto.db) and MatrixAdapter._get_store_dir() (store dir for mkdir/legacy pickle cleanup), both resolving per-call through get_hermes_dir.
  • Update all 7 usages (key-mismatch log, connect mkdir, E2EE setup mkdir, legacy pickle path, sqlite:/// DB URL, E2EE-enabled log, crypto_store_path status) to go through the instance methods.
  • Keep _CRYPTO_DB_PATH = None as a back-compat import alias (no external callers read it, but the name was previously importable).
• tests/gateway/test_matrix_crypto_store_per_profile.py (new)
  • Asserts two profile homes resolve distinct crypto.db paths.
  • Asserts the path is resolved per-call (not pinned at module scope) — switching the active profile changes the resolved path.

Test Plan

MATRIX_E2EE_MODE= venv/bin/python -m pytest tests/gateway/test_matrix.py tests/gateway/test_matrix_crypto_store_per_profile.py tests/gateway/test_matrix_recovery_key_scope.py tests/gateway/test_matrix_plugin_setup.py -q

Result: 121 passed. Also ran test_multiplex_adapter_registry.py + test_multiplex_phase0.py (31 passed) — no multiplex regressions.

(Note: the existing TestMatrixRequirements::test_check_requirements_encryption_false_no_e2ee_deps_ok fails locally when the host env exports MATRIX_E2EE_MODE=required because MATRIX_E2EE_MODE is not credential-shaped and survives the hermetic conftest scrub. It passes with the var unset. That is pre-existing test-env sensitivity, unrelated to this change.)

Verification

• New test passes: two profiles resolve different store paths (verified with set_hermes_home_override, the same contextvar the multiplexer uses).
• grep -n '_get_store_path' plugins/platforms/matrix/adapter.py shows the new per-instance resolver.

[MrSuddenJoy]

This code looks good to me. Well done 👍🏻

[mjshorty]

@MrSuddenJoy — follow-up on this PR from Michael Short. Thanks again for the review; the code hasn't changed since your pass.

Current state as of now:

• Your review on the current head (7f6c9) is positive but was submitted as COMMENTED, not APPROVED — so the PR has no formal approval and is sitting open.
• The branch is 1 commit ahead of main and 1 behind (a simple merge-conflict-free catch-up; nothing blocking).
• No CI checks are configured on this repo, and main has no branch protection, so there's no automated gate waiting on this change.

Could you formally approve and/or pass this to a maintainer for merge consideration? No code changes are pending from our side — if a rebase/merge of main first would help unblock the merge, say the word and we'll push it.

(Note: posting via automation on Michael Short's account — he will not self-merge.)

[MrSuddenJoy]

was submitted as COMMENTED, not APPROVED

@mjshorty thats because both other options are grayed out (not accessible) for me I have to be a contributor to have these 2 enabled.

Could you formally approve and/or pass this to a maintainer for merge consideration?

@mjshorty I would love to, as I see well-crafted code on your side, but I'm not able to technically speaking.

[teknium1]

Thanks @mjshorty — Merged via #101252 (2e25b47) on current main.

Your commits from this PR were cherry-picked onto the salvage branch with your git authorship preserved, so the credit is yours in git log. (Your change was salvaged onto the current code layout where it no longer applied cleanly, but the commit is still yours.)

Closing this PR since the work is now on main.