Users joining a private room within a space via "restricted" join rule have no way of accessing (encrypted) history

### Steps to reproduce

1. Create a space
2. Create a private room in that space
3. Confirm that history visibility is set to shared
4. Set its join rules to be 'restricted' such that anyone in that space can join without an invite
5. Send some messages in the room
6. As a new user, join the space, and join the private room
7. Observe that you have no way of seeing the past history

### Outcome

#### What did you expect?

If the room's history visibility is shared, newly joined users expect to be able to read history.

#### What happened instead?

Newly joined users have no way of reading history \(unless they send keyshare requests to the original sending devices, but that will require those devices to still exist and be online and running in order to service the requests\). Therefore the history will be suppressed.

#### Thoughts

This is a major problem for knowledge exchange within private spaces, as in something like Slack or Rocket.Chat you'd expect to see history when dipping into a channel in a given workspace. Some people workaround this by not enabling encryption on private rooms \(ugh\), but given the default behaviour is to encrypt private rooms, this ends up with a really bad experience of valuable history/context/knowledge being invisible to new members.

Another workaround is to manually export chat history and share as ZIPs within the room when new people join, but this is obviously a horrible hack.

#### Possible solutions

1. You could relax the requirement for which users can share keys with new members: e.g. admins could be allowed to do so, even if they didn't send the original message.. but it still requires their devices to be online. One mitigation could be to always have an admin bot online to manage a space \(could also provide moderation, audit etc\), but this then becomes a highly valuable target given it will amass E2EE keys.
2. You could send all keys for all join-restricted rooms within a space when a user is invited to a space - even if they haven't joined the room yet. This could be a lot of key traffic for conversations you don't care about, however - literally every key for every bit of scrollback the new user might ever want to read. Also, clients in general communicating within a room in a space would need to send megolm keys to every other user in that space, not just the room. This doesn't scale.
3. You could provide a social way for users to request keys off each other, but this is prone to social attacks.

I think the best bet might be option 2, but it's not ideal; other suggestions welcome.

Start with the reproduction steps and the three proposed key-sharing approaches; no implementation files, tests, or entry points are identified in the issue. Research the affected private-room and space membership flows, then establish an agreed design and tests that prove newly joined users can access shared encrypted history without unsafe key distribution.

Written by the indexing model from the issue text.