Feature request: Add a force mode to handle APT locks during patching

First of all, thank you for the new patching functionality. I've been using Patchmon primarily for monitoring, and being able to apply updates directly from Patchmon is a really useful addition.

However, I've encountered a recurring issue with APT locks during patch runs.

For example:

$ apt-get update -qq
E: Could not get lock /var/lib/apt/lists/lock. It is held by process 2152163 (apt-get)
E: Impossible de verrouiller le répertoire /var/lib/apt/lists/

[apt-get update error] exit status 100

--- Patch run failed at 2026-10-01T07:05:35Z ---

This can happen when another APT-related process is already running, for example apt-get, unattended-upgrades, etc.

Before using Patchmon's patching functionality, I handled this in my own update script by checking whether the APT lock was currently held and, when necessary, stopping the process holding the lock before starting the update/upgrade.

Feature request

Would it be possible to add a force mode/option to the patching functionality that handles an existing APT lock?

For example:

Normal mode:
- If the APT lock is busy, wait or fail as it currently does.

Force mode:
- Detect the process holding the APT lock.
- Gracefully terminate it (SIGTERM).
- Wait for the lock to be released.
- If necessary, forcefully terminate the process after a timeout.
- Retry the APT operation.
- Log the process/PID that was stopped.

An alternative could be configurable behavior such as:

apt_lock_behavior = fail | wait | force

I think this would be particularly useful for unattended servers where APT may be triggered independently by unattended-upgrades, timers, or other automation.

One important point would be to handle the process holding the lock, rather than simply deleting the lock file.

This would make the patching feature more resilient on servers where multiple mechanisms can trigger APT operations.