Shared Key | Suspicious double-prefixed localStorage key

### Steps to reproduce

In my local storage, I can see a lot of double prefixed room-shared-key-room-shared-key-

---

Following is from claude:

## Summary

useRoomEncryptionSystem reads and writes the room shared key under a doubly-prefixed localStorage key (room-shared-key-room-shared-key-!room:server), while saveKeyForRoom uses the correct single-prefixed one. The reactive read therefore never sees what the writer writes, and a second copy of every room secret accumulates in localStorage under a key nothing ever reads or cleans up.

Confirmed in practice: affected profiles have numerous room-shared-key-room-shared-key-* entries.

### Outcome

## Root cause

src/e2ee/sharedKeyManagement.ts:

useRoomSharedKey(roomId, setInitialValue) (~L42) expects a room ID and derives the storage key itself: useLocalStorage(getRoomSharedKeyLocalStorageKey(roomId)) (~L46).
useRoomEncryptionSystem (~L90) calls it with an already-prefixed key: useRoomSharedKey(getRoomSharedKeyLocalStorageKey(roomId), …) (~L99).

So the prefix is applied twice. Meanwhile saveKeyForRoom (~L23) writes room-shared-key-.

The junk entries come from useRoomSharedKey's effect (~L53): if (setInitialValue) setRoomSharedKey(setInitialValue) persists the initial value to the doubly-prefixed key on every render where one is present.

### Operating system

_No response_

### Browser information

_No response_

### URL for webapp

_No response_

### Will you send logs?

No

Start in src/e2ee/sharedKeyManagement.ts, especially useRoomSharedKey, useRoomEncryptionSystem, saveKeyForRoom, and getRoomSharedKeyLocalStorageKey. Trace the key passed to the reactive hook against the key used for saving, then verify that reads and writes use one prefix and that the doubly-prefixed entries are no longer produced.

Written by the indexing model from the issue text.