Restart after upgrade is an operations decision, reporter restart_pending.

zabbix-proxy buffers measurements for its nodes. A restart at the wrong time is a gap in exactly the monitoring that is supposed to report the restart.

RULE (dh-s6 >= 1.2.4, POD "Choosing between .noenable and .norestart"):
.noenable answers "first installation", .norestart answers "upgrade of a
running service" -- two questions, two files. .noenable ALONE is already enough
against a start on first installation, because dh-s6 only touches what
'svctl isenabled || svctl isup' affirms. So this file is not here "just to be
safe", but because the TIMING of the outage belongs to operations.

The state it creates -- new package, old process -- is invisible without help.
It is reported by the field restart_pending in aep-zabbix-checks
(>= 0.4.5), per unit, with a WARNING trigger after 1 h. Whoever removes this
file takes the choice away from operations; whoever keeps it must watch the
reporter.

CAUTION, common mistake: .norestart does NOT protect against a restart by
s6-rc-update. Measured on 24.09.2026: a STRUCTURAL change (dependencies,
bundles) restarts the affected longruns, even those nobody changed anything
about -- a dependency change on keepalived took cron down with it. That is why
an s6-policy upgrade on a hypervisor is a maintenance window, and this file
does not help against it.

This file is removed by dh_installs6 during the build and does NOT end up in
the package -- its content is pure documentation for the next session.
