Both sides of upgraded rooms should remain in spaces

Nobody has claimed this yet.

When upgrading a room in a space, the old room and the new room should both remain in the space (the space includes `m.space.child` for both rooms). This is to retain the association and so that future people can still join the room if it uses `restricted` (inherited) `m.room.join_rules`.

Ideally, the behavior of clients would be to show the old room as replaced and de-duplicate it. One problem with this at the moment is that clients not in those rooms are unable to tell that the room has been upgraded because it's part of the room state.

Currently, some clients (like Element Web) workaround this by removing the old room from the space (flawed per the reasons in the first paragraph). This issue is spawning from this behavior being copied into another room upgrade tool and wanting a better path forward.

Related issues:

- https://github.com/matrix-org/matrix-spec-proposals/pull/4168#discussion_r1667766217
- https://github.com/matrix-org/matrix-spec/issues/456
- https://github.com/matrix-org/matrix-spec/issues/1906

### Possible workarounds

Re:

> One problem with this at the moment is that clients not in those rooms are unable to tell that the room has been upgraded because it's part of the room state.

@Kladki [mentions](https://github.com/matrix-org/matrix-spec-proposals/pull/4168#discussion_r2267504115),

> This can be instead addressed by adding `m.room.tombstone` to the list of recommended stripped state events [in the room summaries/space hierarchies].

Start by reviewing the room-upgrade and space-hierarchy behavior described here, then read the linked discussion in matrix-spec-proposals PR 4168 and issues #456 and #1906. Define the specification change that preserves both room references while making upgrades discoverable; done means the protocol behavior and client-facing expectations are unambiguous.

Written by the indexing model from the issue text.