TestRoomKeyIsCycledOnMemberLeaving flake due to tabs?

Nobody has claimed this yet.

```
room_keys_test.go:281: [@user-133-alice:hs1](js) SendMessage !XxmQBbvEwyZPcwXBRN:hs1 => $FDtbPtEoxfcSoOieK88Ztghpl49OmRAvO5zxWEK_J6I
room_keys_test.go:282: @user-134-bob:hs1 (js): Wait[!XxmQBbvEwyZPcwXBRN:hs1]: timed out: bob did not see alice's message
```

Logs show CC: lines for the `Waitf` call as it does `getLiveTimeline` and logs each event. It does not show `/sync` returning any response before it times out 5s later.

Logs before `Waitf`:
```
14:42:31.333184Z [@user-134-bob:hs1,SQMAZNGJZF] console.log FetchHttpApi: --> GET http://127.0.0.1:32814/_matrix/client/v3/sync?filter=xxx&timeout=xxx&since=xxx
14:42:32.283290Z [@user-134-bob:hs1,SQMAZNGJZF] console.log TestRoomKeyIsCycledOnMemberLeaving/{js_hs1}|{js_hs1}: [@user-134-bob:hs1](js) WaitUntilEventInRoom !XxmQBbvEwyZPcwXBRN:hs1
```
This is on the client-as-tab PR, so I wonder if Chrome is throttling the tab..?

Start in room_keys_test.go around lines 281-282 and inspect the Waitf path, including getLiveTimeline and the logged /sync request. Reproduce TestRoomKeyIsCycledOnMemberLeaving with the client-as-tab setup and check whether Chrome tab throttling explains the missing /sync response. Done means the flake is explained and a reliable fix or test adjustment is verified.

Written by the indexing model from the issue text.