Cannot redact messages sent before a room was upgraded

### Description

(Forwarded from https://github.com/vector-im/element-web/issues/23446 )

The missing removal ability for messages in the old copies of upgraded rooms seems like a privacy flaw given the dumping of all "anyone" history rooms on the matrix.org homeserver into the Google index via `view.matrix.org`. Since not only will most people be unaware, once they find out they can't even remove their contents again since the old, otherwise inaccessible pre-upgraded rooms seem to remain indexed. I think that's pretty bad.

### Steps to reproduce

1. Speak in a room with history visibility "anyone"
2. Room gets upgraded
3. Before you click the upgrade button, search any of your old messages still in the old room view and try to delete it. Doesn't work.
4. After clicking the upgrade button you can't even access your messages or see the history anymore, let alone delete it.
5. Find your message on `view.matrix.org` in the google index and that there is no way to delete it, especially once you reached Step 4.

### Homeserver

matrix.org

### Synapse Version

1.69.0rc2 (b=matrix-org-hotfixes,3d5242da14)

### Installation Method

_No response_

### Platform

I'm using the home server with element on the official matrix.org server.

### Relevant log output

```shell
I don't have server access
```

### Anything else that would be useful to know?

I think there is one fundamental condition that should always be satisfied: I should EITHER still have both the permissions to delete all old messages and a practical way to do so after a room upgrade (which means also some easy to find way to access that history), OR all the pre-upgrade messages should get wiped from the homeserver and especially sharing mechanisms like `view.matrix.org`.

Start with the issue's upgrade, redaction, and history-visibility reproduction steps, then review the corresponding Matrix specification rules. Determine whether the protocol needs a defined way to access and redact pre-upgrade messages or a defined removal policy; done means the issue has a clear, agreed specification outcome.

Written by the indexing model from the issue text.