fleetd #360 follow-up: the install block must say loginctl enable-linger

PR #370 shipped both units but its install block stopped at
`systemctl --user enable --now`. Without lingering a user manager starts at
your first login and stops at your last logout, so the units do not come back
after a reboot -- which is the whole reason this ticket moved fleet01 off the
setsid scripts.

It is easy to miss because leaving it out looks like success: `systemctl --user
enable` reports "enabled" and both units run while you stay logged in. The
issue named this and the PR did not carry it over.

fleet01 itself is fine -- measured `Linger=yes`, both units `enabled`. This is
about the next host that follows these instructions.

Comment only; SystemdUnitSafetyTest still 8 green (a commented line is not an
active directive).

deploy/fleetd.service

@@ -12,8 +12,16 @@
 #   # edit WorkingDirectory / ExecStart below for your host's paths and java location
 #   systemctl --user daemon-reload
 #   systemctl --user enable --now herdr fleetd
+#   loginctl enable-linger $USER      # REQUIRED -- see below
 #   journalctl --user -u fleetd -f
 #
+# `loginctl enable-linger` is not optional and is easy to miss, because leaving it out looks like
+# success: `systemctl --user enable` reports "enabled" and both units run for as long as you stay
+# logged in. A user manager without lingering starts at your first login and stops at your last
+# logout, so the fleet simply does not come back after a reboot -- which is the whole reason to
+# use systemd here rather than the setsid scripts these units replaced. Check it with
+# `loginctl show-user $USER -p Linger`; the answer must be `Linger=yes`.
+#
 # Secrets (AI_GATEWAY_TOKEN, WORKER_GITEA_TOKEN, LAVINMQ_URI, COORD_AMQP_URI, ...) are not set
 # here and need no systemd drop-in: ExecStart runs a login shell, so they come from wherever your
 # login shell already sources them (this host: ~/.fleet/secrets.sh via ~/.zprofile). If a token is