EDR reliably takes multiple minutes to start syncing in the morning (recentish regression)

### Steps to reproduce

1. Open laptop in the morning; EDR is already running
2. Stare at a "you are not connected to a server" warning for multiple minutes
3. Remember that it used to clear in ~10s or less (even in a sync v2 world):

Looking at the logs (see rageshake): the app is foregrounded at 09:53:12:

```
rageshake.ts:77 FetchHttpApi: --> GET https://matrix-client.matrix.org/_matrix/client/versions
09:53:12.141 matrix-client.matrix.org/_matrix/client/versions:1 Failed to load resource: net::ERR_INTERNET_DISCONNECTED
09:53:12.141 rageshake.ts:77 FetchHttpApi: <-- GET https://matrix-client.matrix.org/_matrix/client/versions [17ms TypeError: Failed to fetch]
09:53:12.158 rageshake.ts:77 MatrixClient sync state => ERROR
```

...and then only reports sync state SYNCING almost 2 minutes later:

```
09:55:00.955 rageshake.ts:77 MatrixClient sync state => SYNCING
```

Part of this looks to be that the incremental sync took 60s to return:

`09:54:20.210 rageshake.ts:77 FetchHttpApi: <-- GET https://matrix-client.matrix.org/_matrix/client/v3/sync?filter=xxx&timeout=xxx&set_presence=xxx&since=xxx [63324ms 200]`

...but then it takes another 40s to actually process the sync response?! which looks like it might be a EDR perf regression.

### Outcome

#### What did you expect?

Fastish sync on v2 - worst case 30-60s.

#### What happened instead?

2 minutes before you can use the app.

### Operating system

_No response_

### Application version

Element Nightly version: 2024041001 Crypto version: Rust SDK 0.7.0 (61b175b), Vodozemac 0.5.1

### How did you install the app?

_No response_

### Homeserver

_No response_

### Will you send logs?

Yes

Start with the rageshake.ts logs and trace the MatrixClient sync state transition after the failed /_matrix/client/versions request. Compare the timing of the incremental /sync response with the later SYNCING transition, focusing on the reported delay while processing the response. Done means reproducing the morning reconnect scenario and restoring startup syncing to the expected 30–60 second worst case.

Written by the indexing model from the issue text.