Incoming verification request is ignored if it arrives before the device list is updated

Nobody has claimed this yet.

STR are something like:

* Background the EX app
* Log in a new session elsewhere
* From that new session, send a verification request
* Open EX
* Nothing

The problem, as observed from a rageshake, is that the incoming verification request arrives before the device list is updated, meaning it is ignored:

```
2025-05-06T13:06:21.461830Z WARN matrix_sdk_crypto::verification::machine: Could not retrieve the device data for the incoming verification request, ignoring it | crates/matrix-sdk-crypto/src/verification/machine.rs:375 | spans: root > next_sync_with_lock{store_generation=1969} > sync_once{conn_id="encryption" pos="0/m5872750001~1.5872750003~2.5872750005~36.5872750004~3.5872750008_757284974_6725431_m3612552074~72.3612552076_4041061653_265563348_1484733902_11123463783_0_472626"} > handle_response > receive_sync_changes > receive_to_device_event{sender="@dave:matrix.org" event_type="m.key.verification.request" } > receive_any_event{flow_id="891f6afab75d4363b16285a69ddcbe92"}
```

It feels like we should (a) make sure we flag the device list as outdated before processing the to-device messages (i.e., process the device lists part of the sync response before the to-device messages); (b) if the device list is outdated, wait a while to see if it gets updated before discarding the request.

Start in crates/matrix-sdk-crypto/src/verification/machine.rs around line 375 and reproduce the listed sync-order scenario. Trace how device-list updates and to-device verification requests are processed, then determine how an outdated device list should be handled before the request is discarded. Done means an incoming verification request is not ignored when it arrives before the device list update.

Written by the indexing model from the issue text.