Another case of state reset in State Resolution v2

This issue has been migrated from [#15987](https://github.com/matrix-org/synapse/issues/15987).

---

---

**Update:** See https://github.com/matrix-org/synapse/issues/15987#issuecomment-1655485693. This original comment contains grossly incorrect conclusions.

---

### Description

Synapse is responding over the client–server API with a different set of state events depending on whether the requesting user has registered an account or is a guest.

### Steps to reproduce

This bug was discovered in room `!PfltsPSvJVImWNRDyj:matrix.org`. Here is a series of commands to demonstrate the problem:

```sh
# Access token for a registered user account
export USER_TOKEN=''
# Access token for a guest user account
export GUEST_TOKEN=''

export ROOMID='!PfltsPSvJVImWNRDyj:matrix.org'
export HS='https://matrix-client.matrix.org'

export FILTER='[ .[] | walk(if type == "object" then delpaths([["age"],["age_ts"],["replaces_state"],["prev_content"],["prev_sender"],["transaction_id"],["unsigned"],["user_id"]]) else . end | if type=="array" then sort else . end) ] | sort_by(.type)'

curl --no-progress-meter -H 'Accept:application/json' -H "Authorization: Bearer $USER_TOKEN" "$HS/_matrix/client/v3/rooms/$ROOMID/state" | jq -rS "$FILTER" > user_state.json
curl --no-progress-meter -H 'Accept:application/json' -H "Authorization: Bearer $GUEST_TOKEN" "$HS/_matrix/client/v3/rooms/$ROOMID/state" | jq -rS "$FILTER" > guest_state.json
```

Inspection of the output files `user_state.json` and `guest_state.json` reveals wildly different sets of state events, even though both come from _the same homeserver_. For example:

user_state.json

```json
{
"content": {
"join_rule": "public"
},
"event_id": "$W8ilz2XuqXYU3LilZkU3BLlbGvQgxGMBn5BY81SmBP0",
"origin_server_ts": 1687249386275,
"room_id": "!PfltsPSvJVImWNRDyj:matrix.org",
"sender": "@wj25czxj47bu6q:matrix.org",
"state_key": "",
"type": "m.room.join_rules"
}
```

guest_state.json

```json
{
"content": {
"join_rule": "invite"
},
"event_id": "$lZoXigGI2_plf_Hdj47IDmYPeoV00te_jgkVQGToJJo",
"origin_server_ts": 1686004259002,
"room_id": "!PfltsPSvJVImWNRDyj:matrix.org",
"sender": "@moderation-tools:matrix.org",
"state_key": "",
"type": "m.room.join_rules"
}
```

In this case, the `m.room.join_rules` reported to registered users is the correct one, while the `m.room.join_rules` reported to guest users is an old event which has been replaced.

This also does not appear to have any relation with `m.room.guest_access`, which was set to `"guest_access": "forbidden"` long before either of the `m.room.join_rules` state events displayed above were sent.

### Homeserver

matrix.org

### Synapse Version

1.88.0

### Installation Method

I don't know

### Database

I don't know

### Workers

I don't know

### Platform

I don't know

### Configuration

_No response_

### Relevant log output

_No response_

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

This issue seems to have cropped up very recently, perhaps in Synapse v1.88.0 or v1.88.0rc1, though it is also entirely possible that it just went unnoticed until now.

Reproduce the discrepancy using the provided curl commands against the client-server `/rooms/$ROOMID/state` endpoint, comparing registered-user and guest responses. Trace the state-resolution path for the returned `m.room.join_rules` event; done means both access types return the current, correct state rather than an obsolete replaced event.

Written by the indexing model from the issue text.