refactor: extract CryptoFacade, introduce RoomMemberCache

[axel-krapotke]

Motivation

The CryptoManager was directly injected into TimelineAPI, CommandAPI, and Project — each module contained its own copy of the crypto orchestration ceremony. This violated separation of concerns and made the code fragile and hard to maintain.

Changes

CryptoFacade (src/crypto-facade.mjs)

• New facade that encapsulates all crypto orchestration in one place
• Owns the CryptoManager and HttpAPI references
• The 7-step encrypt ceremony (trackUsers → queryKeys → claimSessions → shareRoomKey → encrypt → processOutgoing) exists exactly once
• Historical key sharing ceremony exists exactly once

RoomMemberCache (src/room-members.mjs)

• Self-sufficient cache: fetches members from the server on cache miss via a constructor-provided callback
• Updated by sync stream membership events (addMember/removeMember)
• Guards against network errors on cache miss (returns empty array)
• Eliminates per-message HTTP lookups for room members during encryption

API Changes

• TimelineAPI: Constructor takes options with onSyncResponse and decryptEvent callbacks instead of a crypto object
• CommandAPI: Constructor takes memberCache (RoomMemberCache) as second parameter; optional encryptEvent in options
• Project: Takes memberCache and crypto options object with isEnabled, registerRoom, shareHistoricalKeys
• HttpAPI: processOutgoingCryptoRequests() removed (moved to facade)
• index.mjs: Single composition root wiring everything together

Principles Applied

• No module except CryptoFacade and index.mjs knows CryptoManager exists
• Cache is a proper collaborator, not a callback trio
• Membership events: filter once, then update cache, then notify handler (separate steps, no side effects during mapping)

E2E Tests

All test files updated for the new API signatures. Test logic and assertions unchanged.