UTD: the sender had the wrong list of room members

Nobody has claimed this yet.

We have two rageshakes where the [receiver](https://github.com/element-hq/element-x-ios-rageshakes/issues/3760) is unable to decrypt a message from the [sender](https://github.com/element-hq/element-web-rageshakes/issues/29503).

The sender (on EXI) joined the room about 5 minutes before sending the message, and they did a successful `_matrix/client/v3/rooms/!CiYGrGEhmfqDgqjdKq:one.ems.host/members` request (size 2.8k), presumably saving the members list to their local store.

Just before sending the message, they sent out their sender key/session, but only to themself.

Then they sent the message and it was UTD for the receiver.

Then later they sent out the session again for a later message, and this time they included the receiver's devices.

So it looks like they had the wrong list of members of this room. Maybe they somehow raced with the NSE process to write to the local store? (We have no NSE logs - I don't know why.)

There are also a lot of lines like this in the sender logs:

```
2025-05-07T07:28:26.946012Z ERROR elementx: Failed checking if the user can redact self with error: Generic(msg: "unknown error: Local cache doesn\'t contain all necessary data to perform the action.", details:
Optional("UnknownError(Local cache doesn\'t contain all necessary data to perform the action.\n\nStack backtrace:\n 0: std::backtrace::Backtrace::create\n 1: anyhow::error:: for a
nyhow::Error>::from\n 2: >::from\n 3: as core::future::future::Future>::poll\n 4: uniffi_core::ffi::r
ustcalls::rust_call_with_out_status\n 5: as uniffi_core::ffi::rustfuture::future::RustFutureFfi<>::ReturnType>>::ffi_poll\n 6: _ffi_matrix_sdk_ffi_rust_future_poll_i8\n 7: ___swift_memcpy57_8\n 8: \n 9: \n 10: \n 11: \n 12: )")) | JoinedRoomProxy.swi
ft:593 | spans: root
```

which might imply that the room information is somehow missing from the store?

Start with the sender's `/members` request and the sender-key/session delivery sequence described in the rageshakes, then investigate how the local store and NSE process provide room-member data. Use the `JoinedRoomProxy.swift:593` error as a related symptom. Done means identifying and addressing the cause of the incomplete member list, with a regression test or reproduction covering the affected encryption flow.

Written by the indexing model from the issue text.