docs(installer): record the first real systemd verification

Phase 2 shipped service registration that had never been executed: a
relocated test run deliberately skips it, `sc create` needs elevation,
and systemd needs a Linux host. It has now been run for real on a
privileged Debian 12 container with systemd as PID 1 — unit written and
enabled, service up as the unprivileged runicgateway user, sidecar.toml
600 and owned by it, database under /var/lib (so the UOLINK_DB_PATH pin
works), /health answering protocol 3, and uninstall taking the service,
unit, binary and account away while leaving the config, the database and
the whole ServUO tree alone.

That surfaced one bug only a real service host could show — user_created
was recorded per-run rather than as state, so an identical re-run
rewrote install.json and uninstall silently left behind the account the
installer had created (installer#8). Recorded here with the reason it is
invisible on Windows.

Also notes what is still unverified: the Windows SCM half, which needs an
elevated shell this machine's automation does not have.

Co-Authored-By: Claude <noreply@anthropic.com>

installer/PLAN.md

@@ -632,6 +632,29 @@ second run reporting `unchanged` / `already present` and leaving `install.json`
 `--verify` run over an installed host writing nothing and preserving the `link` section, and a
 tampered binary detected by hash and replaced with no stray staging file left behind.
 
+**Service registration itself stayed unverified until Phase 4** — a relocated run deliberately
+skips it, `sc create` needs elevation, and systemd needs a Linux host. It has now been run for
+real, on a privileged Debian 12 container with systemd as PID 1, installing into `/usr/bin`,
+`/etc/runicgateway` and `/var/lib/runicgateway` as root: the unit is written and `enable`d, the
+service comes up `active, enabled` as the unprivileged `runicgateway` user, `sidecar.toml` lands
+`600` owned by it, the database is created under `/var/lib` (so the `UOLINK_DB_PATH` pin works),
+`/health` answers protocol 3, and `uninstall` takes the service, the unit, the binary and the
+account away again while leaving `sidecar.toml`, the database and every overlay file in the ServUO
+tree untouched.
+
+Doing that found one bug that only a real service host could show, fixed in
+[installer#8](https://gitea.whitlocktech.com/RunicGateway/installer/pulls/8): **`user_created` has
+to be sticky.** `service::prepare` answers "did *this run* create the account", which is false from
+the second run on, so recording it verbatim made the field describe the run rather than the state —
+the same class as Phase 1's two live-run bugs. It rewrote `install.json` on an identical re-run,
+and it made `uninstall` (which removes only an account it created) silently leave behind the very
+user this tool had added. The record now inherits `true` from a prior record naming the same
+account, and only that one. Windows never showed it because the SCM's virtual account is not
+something the installer creates.
+
+**Still unverified: the Windows SCM half.** `sc create` demands elevation, and this machine's
+automation runs unelevated; the systemd half above is the platform that could be driven end to end.
+
 ### Phase 3 — patch tier (opt-in)
 
 Everything in §2.2. Detect applicability, dry-run, apply, record, warn about the core rebuild, and