Logout results in confusing repetitive dialogs and inaccurate scary red warnings about device verification even though encryption is disabled

### Steps to reproduce

We have specifically disabled encryption on this instance using `encryption_enabled_by_default_for_room_type: off`, in order to tame the UX complexity that comes with Element/Matrix's encryption. This user is only in one room, which is unencrypted.

1. Logout from Element Web session

2. Log back in

### Outcome

#### What did you expect?

Be logged in and see conversations with their history (given that this server has encryption disabled).

#### What happened instead?

0. When logging out, no info is displayed about any sort of verification or keys that would be needed to log back in.

1. When logging back in, a "dialog" says the device needs to be verified ("confirm identity"), but effectively only offers the option to say it is impossible to confirm the identity (or alternatively log out, then log back in and be facing the same exact situation). If the system is able to detect that it is impossible for the user to confirm their identity, it should not ask the user to do so.

If the user is curious enough to click the cross to close this dialog, they are offered the possibility of not verifying the device. If this possibility is desired (#31073 makes me think it is not), it should be among the listed options, not hidden in the close button. Furthermore, the new dialog that appears in that case has the option which does *not* cause data loss in red, which is misleading.

If however one doesn't close the dialog at step 1 and instead clicks the main button (unable to confirm), then they see step 2:

2. An incorrect scary confusing red warning "dialog" explains that the user's message history will be lost (scary), even though in practice messages in unencrypted rooms are not lost (incorrect) and that all devices will need to be re-verified (confusing, we are in this situation precisely because there are no verified devices which can be used to cross-sign this new device, while the statement is mathematically true, most non-math-savvy users will understand "all" to mean "at least one"). The user then has to click on the red button, which is problematic: if a button is scary red, it should be because it is the dangerous option *as opposed to a safer option*. However, in this case, *there is no* safer option: the only alternative is to click cancel which returns to step 1, itself offering only the options of going back to step 2 or logging out then logging in to be back at step 1. The scary red UI design should be used when the dangerous action is taken (i.e. when logging out, or when doing any action in app without having exported recovery keys because the browser may delete the cookies for a variety of reasons without displaying any UI from Element Web), not when it is already too late and there is no option to log in without accepting to loose the history.

3. A third "dialog" appears. I'm not sure what this one's role is supposed to be: it explains you need to click the black button, then click retry, but in practice it is not necessary to click retry (at step 5 this dialog appears for a fraction of a second and seems to retry on its own without any user interaction). So it's not a real choice (clicking retry before the black button does nothing), the second half of the information is incorrect (tells you to click retry at step 5 but you can't because it clicks itself too fast), and the first half just tells you that you need to click a button to proceed. Maybe this click can be automated, just like the click on retry is automated?

You'll notice that in the background of there is a green badge next to a text saying the device is verified. If one is adventurous enough to close this third dialog, they see the second dialog again, at which point clicking "cancel" actually logs the user in (but going to settings → encryption, I can see that the device is not actually verified — so the green badge and accompanying text are also incorrect information).

If instead of closing the dialog one clicks on the black button, one gets to step 4:

4. A fourth "dialog" appears. This is essentially the same UI as dialog 2, but with a different layout. If the red button was clicked at step 2 in order to confirm a dangerous action, it should not be necessary to re-confirm. I understand step 2 is displayed by Element Web, whereas step 4 is displayed by the MAS. Given the desire to have a separation of concerns between these two components, either Element Web should not show step 2 (and requests that the MAS takes care of this confirmation), or it should ask the MAS for a form of authentication which does not come with such a confirmation (e.g. specifying `?confirm=no` or something functionally equivalent). Either way, in such a case, it is necessary to ensure the two components communicate enough information to avoid duplicating the dialogs displayed to the user, especially if those dialogs contain scary red buttons.

5. At this point, the dialog of step 3 appears for a fraction of a second, then disappears, and the user is logged in.

I have written "dialog" in quotes in the steps above, because none of these are true dialogs, rather they are a linear monologue which most likely will scare and confuse the user, where the only alternative at each step is to go back to the previous step or log out (apart from the equally confusing behaviour obtained by clicking the cross to close the dialog at steps 1 and 3, which are the only ways to log in without comitting to loose unencrypted messages — even if in practice the messages are not lost either way).

Note that I, personally, do not have a problem with exporting recovery keys and using them to verify a new device (or making sure an already-logged-in device exists at all times), however less tech-savvy users should be expected to feel confused, worried, unsure of how many clicks will resolve the situation, and I fear the process might make them feel like they are being reprimanded for having logged out (without any indication that this action is risky or problematic) by four monologue boxes scaring them into expecting message losses — even though no (unencrypted) message is being lost in the end — without actual educational material which would help them understand what is verification, how the verification of a device benefits them, what undesirable behaviour that verification prevents, and how to avoid ending up in this situation again in the future.

### Operating system

Linux

### Browser information

140.10.2esr (64-bit)

### URL for webapp

ESS 26.3.1

### Application version

Version de Chat : 1.12.13 Version crypto : Rust SDK 0.16.0 (1ac734e), Vodozemac 0.9.0

### Homeserver

Synapse from ESS 26.3.1

### Will you send logs?

No