Delayed membership responses in /sync cause UTDs

Nobody has claimed this yet.

This outlines a race condition in the CSAPI which can cause UTDs.

Consider:
- Alice is in a E2EE room and invites Bob. The request 200 OKs but has yet to come down /sync.
- Alice tries to send a message in the room.
- Alice should encrypt for Bob.

In practice, clients will not encrypt for Bob, causing a UTD if you very quickly send an encrypted message after inviting a user. This can happen due to:
- A bot is using the SDK so message sending is very quick after an invite
- DMs: for better UX a room is only made / user invited / message sent, when someone _sends_ a message in a DM room rather than just selects the user's room. This means the message is already ready to go at the same time as invite time.

To fix this, we should be remembering that we, the client, have modified the membership state of the room, and invalidate the room member list (so we hit /members again). We can't assume that a 200 OK to /invite will guarantee that the user is in an invited state, so we still need to defer to the server.

A test for this is in https://github.com/matrix-org/complement-crypto/pull/98

Start by tracing the SDK's handling of /invite, /sync, and /members in the race described above. Review the linked complement-crypto PR #98 for the proposed regression test and expected behavior. Done means a membership change is reflected before encryption and the rapid invite-then-send scenario no longer causes UTDs.

Written by the indexing model from the issue text.