Refactor: weiteres Splitten von useMatrixClient (Chat, Medien, Crypto, …)

[mjkatgithub]

Ziel

app/composables/useMatrixClient.ts ist auch nach Auslagerung der Registrierung (matrixRegistrationUia.ts, matrixClientShared.ts) noch > ~1000 Zeilen. Lesbarkeit, HMR und Review-Groesse verbessern, ohne das oeffentliche useMatrixClient()-API fuer Aufrufer zu aendern (oder Aenderungen explizit und versioniert machen).

Vorschlag zur Schnittbildung

• Eigenes Modul z. B. matrix/messages.ts / Composable-Wrapper: sendMessage, sendImageMessage, Reactions, Timeline, Verschluesselung-Pfade die nur dort gebraucht werden.
• Eigenes Modul matrix/roomsOrDirectory.ts: searchPublicRooms, searchUsersDirectory, ggf. Join/Create-Room, falls klar abgrenzbar.
• Ggf. Session-Storage / Rust-Crypto-Init in eigenes matrix/sessionCrypto.ts (sichtbare Grenze zu reiner HTTP-Logik).
• useMatrixClient.ts orchestriert und re-exportiert, wo sinnvoll, analog zu matrixRegistrationUia.

Akzeptanzkriterien

• Keine funktionalen Regressionen: bestehende Unit- und E2E-Tests gruen; bei API-Aenderung Migration und CHANGELOG (falls oeffentliche Exporte betroffen).
• useMatrixClient.ts deutlich unter Ziel (z. B. < 800 Zeilen) oder mehrere fokussierte Dateien a < ~500–800 Zeilen mit klarer Verantwortung pro Datei (im PR begruenden).
• Kein unnoetiger Wildwuchs an neuen Doppel-Abstraktionen; nur splitten, wo Lesbarkeit gewinnt.

Nicht im Scope

• Bundle-Chunk-Optimierung (Vite) – eigenes P1-Issue (Vite/rollup manualChunks / Warnungen).