UISIs after upgrading dendrite

*This issue was originally created by [**@kegsay**](https://github.com/kegsay) at .*

### Background information

- **Dendrite version or git SHA**: 0.10.7+31f56ac3
- **Monolith or Polylith?**: Monolith
- **SQLite3 or Postgres?**: Postgres
- **Running in Docker?**: No
- **`go version`**: go version go1.19.3 windows/amd64
- **Client used (if applicable)**: Element Desktop (both sender/receiver)

### Description

- **What** is the problem: UISIs on previously fine group chat room.
- **Who** is affected: Single user
- **How** is this bug manifesting: Unable to decrypt: The sender's device has not sent us the keys for this message.
- **When** did this first appear: After upgrading from `7ad87eace3b88b3aaa88dc8a0acec9b64ffcc52c`

### Steps to reproduce

Filed on behalf of @emanuele.aliberti:mtka.eu - who sent a screenshot which indicates that:
- Previously decrypted messages remain decrypted.
- New messages after the upgrade are UISIs.
- Neither Element client was restarted in the interim.

The room key must have changed, but why this wasn't shared post upgrade I don't know. It could be that the room key happened to change during the downtime between upgrades, but this should have been retried.

After restarting both Element instances, _new messages_ are decrypted, but previous UISIs remain as UISIs. This may point to an Element Desktop bug.

Start by reproducing the reported UISIs using Dendrite 0.10.7+31f56ac3 with a monolithic Postgres deployment and Element Desktop clients, comparing behavior before and after the upgrade from 7ad87eace3b88b3aaa88dc8a0acec9b64ffcc52c. Check server logs and client behavior around room-key sharing and retrying; done means previously affected messages decrypt without requiring manual client restarts.

Written by the indexing model from the issue text.