feat: re-add "second device added" message if deleted soon after transfer (#8758)

this PR makes it easier to spot unwanted "add second device" actions, if
the unlocked device is left unattended and/or a system lock is not in
place (so cannot be checked directly before doing the "add second
device" action).

already today, the sending device gets the message "ℹ️ Profile
transferred to your second device", which, however, can be deleted.

with this PR, if the message is deleted soon after the transfer, it
first looks as if this was successful. however, the message is re-added
later, at the first housekeeping at least an hour after the transfer.
deleting the message after that is final, so users can still get rid of
it.

It is clear that this does not catch all eventualities, it is
best-effort. e.g. it is known that subsequent "add second device"
attempts remove checks of previous ones.
First line of defense is device locking and asking for secret explicitly
before adding a second device.

previous discussions about that at
https://github.com/chatmail/core/issues/4303

src/sql.rs

@@ -14,7 +14,7 @@ use crate::config::Config;
 use crate::context::Context;
 use crate::debug_logging::set_debug_logging_xdc;
 use crate::ephemeral::start_ephemeral_timers;
-use crate::imex::BLOBS_BACKUP_NAME;
+use crate::imex::{self, BLOBS_BACKUP_NAME};
 use crate::location;
 use crate::log::{LogExt, warn};
 use crate::message::MsgId;
@@ -827,6 +827,12 @@ pub async fn housekeeping(context: &Context) -> Result<()> {
         );
     }
 
+    imex::maybe_readd_backup_transfer_msg(context)
+        .await
+        .context("Failed to re-add backup transfer message")
+        .log_err(context)
+        .ok();
+
     if let Err(err) = incremental_vacuum(context).await {
         warn!(context, "Failed to run incremental vacuum: {err:#}.");
     }