auto update requires user interversion if power is lost during upgrade

Describe the bug

The auto update feature deadlocks permanently, requiring user intervention, if the power is lost during an upgrade if the upgrade process is interrupted in certain moments.

For example, if a laptop battery goes out during the "Setting up" phase that you can see in /var/log/apt/term.log, it may leave the system in a broken state, requiring a user to press either the 'Install Updates' or 'Refresh' button to have the upgrade finish successfully and have the next scheduled upgrade to start.

Steps to reproduce

1. Enable auto updates by checking the box 'Apply updates automatically'.
2. Wait for the scheduled upgrade to start. (Force with systemctl start mintupdate-automation-upgrade)
3. Power computer down after package are extracted but before they are configured. Likely when you see "Setting up", as mentioned above.
4. Power computer back up.
5. Notice how the system won't be automatically updated again.
6. Also useful to notice: apt upgrade will complain that dpkg --configure -a should be run manually.

Expected behavior
Expected to for mintupdate to be resilient against unexpected shut downs.

Distribution

• Linux Mint
• LMDE

Software version
7.1.4

Additional context

This is relevant because it makes the system vulnerable for longer before the user is notified. Also relevant for less tech-savy users as they may not notice or take action about the notifications warning the system has been out-of-date for days. Also affects users that remove mintupdate from the 'auto start application' list and rely only on the provided systemd timer to apply the upgrades.

mintupdate will continue to 'refresh' periodically, showing more packages that need upgrading as new ones appear, but it won't fix the dirty state. The systemd service can't recover from this dirty state, so the system stays outdated.

Preliminary testing on the master branch suggests it is also affected by this issue: mintUpdate.py periodic refreshes don't seem to fix the dirty state, and mintupdate-cli.py can't handle it when launched from the systemd service.

Start by tracing the systemd-triggered upgrade flow through mintUpdate.py and mintupdate-cli.py, using /var/log/apt/term.log and the reported dpkg --configure -a state to reproduce the interruption. Check how the service handles an incomplete upgrade after reboot. Done means the scheduled auto-update recovers from the dirty package state without requiring the user to press Install Updates or Refresh.