docs: exe-setup.service runs on every boot, so setup scripts must be idempotent

[ryanlewis]

Why

The README described exe-setup.service as first-boot-only in two places. That holds for the first boot and not afterwards: exe.dev writes /exe.dev/setup back into the VM on every boot, ConditionPathExists passes again, and the script runs again. The ExecStartPost rm still deletes the file each time; it just comes back.

Reproduced on a stock boldsoftware/exeuntu VM with a four-line script containing a bare useradd --system: first boot succeeded, second boot exited 9 (user already exists), the unit stayed failed, and systemctl --failed went from 0 to 1. Surfaced for real while migrating html-share to exeslim, where the setup script creates the caddy user.

What changes

• The two README rows now say the unit runs on every boot.
• New README subsection "Setup scripts run on every boot" explains the platform behaviour, the failure mode, and shows the guard pattern (id -u caddy || useradd …).
• The unit's Description= no longer says "on first boot".

No behaviour change. The section also records that the script cannot be amended after new (no CLI command, and on-box edits are overwritten from the stored copy at every boot), so the guard must be right at creation time, and that ssh exe.dev doc customization claims first-boot-only. The unit is identical to exeuntu's apart from the description string.

Not done: a stamp-file guard

The unit could be made genuinely first-boot-only:

[Unit]
ConditionPathExists=!/var/lib/exe-setup.done
[Service]
ExecStartPost=/usr/bin/sudo /usr/bin/touch /var/lib/exe-setup.done

Left out because it diverges from exeuntu (a script that relies on re-running would stop) and because it changes retry semantics: ExecStartPost only runs on success, so a script that fails on boot one would still retry on boot two, which may or may not be wanted. Reporting the re-injection upstream to boldsoftware is a separate call.