Restart after upgrade is an operations decision, reporter restart_pending.

zfs is a ONESHOT (pool import and mount -a): 'svctl restart' takes it down and
up again, and everything that depends on zfs goes down with it and does NOT
come back by itself -- s6-rc dependency semantics. On a hypervisor or data
node that is a maintenance window (orchestrator 23.09.2026). Today zfs on
infra-1.tick1 has no dependents in the live database; that can change with any
unit that registers 'zfs' as a dependency.

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 already suffices
against a start on first installation, because dh-s6 only touches what
'svctl isenabled || svctl isup' confirms. 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. Therefore
an s6-policy bump on a hypervisor is a maintenance window, and this file does
not help against that.

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.
