fix: Fix setting up a profile and immediately transferring to a second device (#6657)

Found and fixed a bug while investigating
https://github.com/chatmail/core/issues/6656. It's not the same bug,
though.

Steps to reproduce this bug:
- Create a new profile
- Transfer it to a second device
- Send a message from the first device
- -> It will never arrive on the second device, instead a warning will
be printed that you are using DC on multiple devices.

The bug was that the key wasn't created before the backup transfer, so
that the second device then created its own key instead of using the
same key as the first device.

In order to regression-test, this PR now changes `clone()` to use "Add
second device" instead of exporting and importing a backup. Exporting
and importing a backup has enough tests already.

This PR also adds an unrelated test `test_selfavatar_sync()`.

The bug was introduced by https://github.com/chatmail/core/pull/6574 in
v1.156.0

src/imex/transfer.rs

@@ -45,7 +45,7 @@ use crate::message::Message;
 use crate::qr::Qr;
 use crate::stock_str::backup_transfer_msg_body;
 use crate::tools::{create_id, time, TempPathGuard};
-use crate::EventType;
+use crate::{e2ee, EventType};
 
 use super::{export_backup_stream, export_database, import_backup_stream, DBFILE_BACKUP_NAME};
 
@@ -109,6 +109,11 @@ impl BackupProvider {
             .parent()
             .context("Context dir not found")?;
 
+        // before we export, make sure the private key exists
+        e2ee::ensure_secret_key_exists(context)
+            .await
+            .context("Cannot create private key or private key not available")?;
+
         let dbfile = context_dir.join(DBFILE_BACKUP_NAME);
         if fs::metadata(&dbfile).await.is_ok() {
             fs::remove_file(&dbfile).await?;