fix(packaging): an upgrade must not stop and disable the agent — 0.1.9

dpkg calls the OLD package's prerm on an UPGRADE as well as on a removal (rpm passes a
remaining-instance count), and preremove.sh ran `systemctl disable --now monky-deployd.timer`
unconditionally. Upgrading env-dev-01 and env-dev-08 to 0.1.8 today stopped and disabled both
agents.

The failure is silent, which is the dangerous part: the box stays reachable, the containers keep
running, and nothing reports that check-ins have ceased — the backend just stops converging. A
fleet upgrade would have taken every agent offline at once and looked like a success.

preremove.sh now returns early for every upgrade shape (upgrade, failed-upgrade, deconfigure,
rpm's 1) and only disables on a real removal. postinstall.sh try-restarts the long-lived proxy
unit so it picks up the new code; the timer needs nothing, since each tick is a fresh process.

Tests drive the script with a fake systemctl on PATH and assert an upgrade touches no units.
OPERATIONS.md warns that a box coming FROM 0.1.8 or earlier still needs its timer re-enabled by
hand, because the old prerm has already run by then.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KLB7jieMNRkTsJ2epr4Ds1

docs/OPERATIONS.md

@@ -30,6 +30,10 @@ the `ziti` **group**, plus an explicit ACL `u:monky-deployd:r` and a default ACL
 > first refresh and then fails every tick (env-dev-08, 2026-09-09). On a host where the tunneller was
 > installed independently of the kit, check `id monky-deployd` for `ziti` before anything else.
 
+> **Upgrading the agent.** `dpkg -i` keeps the timer enabled from 0.1.9 on. On a box upgraded from
+> 0.1.8 or earlier the old package's `prerm` already ran and **disabled** it — check
+> `systemctl is-enabled monky-deployd.timer` after the upgrade and `systemctl enable --now` it if needed.
+
 ## Reading the journal
 
 | line | meaning |