Found on the first real systemd host this installer has ever run on: a
container with systemd as PID 1, installing into /usr/bin, /etc and
/var/lib for real.
`service::prepare` answers "did THIS run create the service account",
which is false on every run after the first — by then the account exists.
Recording that verbatim made the field describe the run rather than the
state, with two consequences:
- `install.json` changed on an otherwise-identical second run, breaking
the Phase 1 promise that a re-run with nothing new to do writes
nothing.
- `uninstall` removes only an account it created, so after any second
`install` it silently left behind the very user this tool had added.
Reproduced before the fix: "left the runicgateway account alone — this
installer did not create it", on a host where it plainly had.
The record now inherits `true` from a prior record naming the same
account, and only that account: inheriting across a rename would
authorize deleting a user this installer never made.
Not visible on Windows, where the SCM's virtual account is never created
by us and goes with the service — which is why three phases of Windows
smoke runs never showed it.
Verified after the fix on the same host: fresh install records
user_created true, an identical second run leaves install.json
byte-identical, and uninstall then removes the account, the unit, the
service and the binary — leaving sidecar.toml, the database and all 24
overlay files in the ServUO tree exactly where they were.
Co-Authored-By: Claude <noreply@anthropic.com>
wtclaude
e55c9d5caa