scripts: hook apply-mbps-caps into the PVE host as a systemd timer

The qm-set I/O caps were previously only applied by manual one-shot
runs of apply-mbps-caps.sh, so any config drift (manual `qm set`,
config restored from /mnt/backup/pve-config like we did on 2026-05-26,
fresh VM clone) would leave the affected VM uncapped until someone
remembered to re-run the script.

Adds apply-mbps-caps.service (Type=oneshot) + apply-mbps-caps.timer
firing:
  - OnBootSec=5min        — catches PVE host reboots & restored configs
  - OnCalendar=hourly     — catches manual qm-set drift / fresh clones
  - Persistent=true       — runs missed schedule after PVE downtime
  - RandomizedDelaySec=2min

Same install pattern as the other PVE operational scripts (nfs-mirror,
daily-backup, offsite-sync-backup, lvm-pvc-snapshot — memory id=609 +
id=542). Source in this repo, deployed to /usr/local/bin + /etc/
systemd/system/ on the PVE host.

Script hardening: kept `set -uo pipefail` but dropped `-e` so one
missing VM doesn't abort the rest; each VM is gated on `qm status`
existence; added a fast-path "already at target" no-op log line for
quiet hourly runs.

Installed on PVE (192.168.1.127) and smoke-tested: all 8 VMs caps
re-applied successfully, next run 12:00 EEST. Journal: `journalctl
-u apply-mbps-caps -f` on the PVE host.

scripts/apply-mbps-caps.timer

@@ -0,0 +1,18 @@
+[Unit]
+Description=Re-apply per-VM I/O caps periodically + after PVE boot
+
+[Timer]
+# After every PVE host reboot — caps survive in /etc/pve/qemu-server/<vmid>.conf
+# normally, but a config restore from backup can drop them (see 2026-05-26
+# incident where we restored 202.conf + 203.conf from /mnt/backup/pve-config/).
+OnBootSec=5min
+
+# Hourly during normal operation — catches manual `qm set` drift or fresh
+# VM clones that haven't had caps applied yet.
+OnCalendar=hourly
+
+Persistent=true
+RandomizedDelaySec=2min
+
+[Install]
+WantedBy=timers.target