### Impacted versions
19.0 (the same applies to every branch shipping `base/data/neutralize.sql`)

### Steps to reproduce
1. On a database with an outgoing mail server configured with a username and password, neutralize it (`odoo-bin neutralize`, or restore/duplicate with neutralization enabled).
2. Look at the `ir_mail_server` row.

### Current behavior
The server is archived, so the database can no longer send. `smtp_user` and `smtp_pass` are left untouched, so the credentials stay in the database and travel with every dump taken from it. The password still authenticates against the real relay.

### Expected behavior
Neutralization is what turns a production database into one that can be copied and handed around — a staging build, a dump downloaded for debugging. A database that is not allowed to send mail has no use for a credential to send it with, and keeping it means the credential leaves the platform with the copy.

### Fix
Clear `smtp_user` and `smtp_pass` in the same statement that archives the servers. The stub relay inserted just below still blocks the fallback to the command-line SMTP settings, so behavior is unchanged otherwise.

Tested by seeding a mail server with credentials, running the file, and checking the row: archived, credentials empty, stub relay present.

Forward-Port-Of: odoo/odoo#284960

1. Bootstraping fix

This commit fixes the session fingerprint bootstrapping. When the webclient loads, we ensure that the fingerprint is initialized in the backend.
If the session does not have a fingerprint, we cannot perform the verification.

The result is:
Only internal users using the webclient will benefit from this additional layer of security.
Other uses (scripts, etc.) are not affected by this feature.

2. Fingerprint check fix

The function `updateFingerprint` must return a negative response if an error occurs and thus continue the verification process (which requires that the system not be offline). We cannot ignore an error. This is because the original RPC will be replayed (without the wrapper that handles the `CheckIdentityException` exception). It is therefore necessary to remain in a state where the user can verify his identity.

3. Auth form mounted for trusted device fix

The update of the fingerprint according to the event `WEB_CLIENT_READY` occurs at an "arbitrary time". If a form is currently being mounted (because an untrusted device is being used) but the fingerprint update marks that device as trusted in the backend (no matter the reason), then when we call `/web/session/identity/check` without any data to retrieve the reauthentication methods, the fingerprint check method will no longer be possible[^1].
As a result, the form is mounted for a trusted device (and not perform fingerprint check).

This issue is solved because we use the new route `/web/session/identity/set` when the `WEB_CLIENT_READY` event is triggered and the backend logic doesn't update device information. We update only session information.

[^1]: https://github.com/odoo/odoo/blob/7c6f31d730304bca3f6c996800e76d1e40ce4adf/odoo/addons/base/models/ir_http.py#L563

Task-6373219