Logout is non-atomic, network dependent and without feedback to the user

### Background

Whilst investigating causes of logouts in Element Desktop/Web I have observed a recurring pattern of inconsistent storage state on clients *following* a logout.

Important: this issue is distinct from any *causes* of the original logout.

### Typical symptoms

User sees the "Unable to restore session" modal and the log contains:

```
No pickle key available for ${userId}|${deviceId}
Unable to load session Error decrypting secret access_token: no pickle key found
```

If you then look at the previous logs you will find that there is a logout indicated by `MatrixChat: handling action logout` but no subsequent log line saying `Clearing storage, deleteEverything=true` meaning that storage was not actually cleared.

> [!TIP]
> Disambiguation: this is not the only cause of the "no pickle key" errors. The key indicator is the *earlier* log entries showing that a logout was started but didn't complete fully.

### Diagnosis

`Lifecycle.logout()` performs and ordered sequence of steps including:

1. destroys the pickle key
2. request the server invalidate the server-side session
3. stop the MatrixClient and clear storage

The user is not given any feedback to say that the logout is in progress. The request to the server in step 2 could take a long time or timeout depending on network conditions. This means that the user may give up and close the client prematurely whilst the logout is still in progress (i.e. whilst step 2 is still happening).

This occurs on both Legacy and OAuth authentication methods.

### Remediation

Thoughts:

- I think we should give visual feedback (and block further action) whilst the logout is in progress
- Is the sequencing of the actions still correct?
- Should we do more in parallel?

Start at Lifecycle.logout and the MatrixChat logout handling, then trace both Legacy and OAuth logout flows. Reproduce the delayed or interrupted server request and inspect the ordering around pickle-key destruction, server invalidation, client shutdown, and storage clearing. Done should include clear in-progress feedback, blocked further actions, and reliable completion of logout storage cleanup.

Written by the indexing model from the issue text.