`caddy validate` run as root creates the log files the config names, owned by
root. The caddy user then cannot open them and the reload fails with
'permission denied' on the log writer — which is exactly what happened on the
live cutover, and what the root-owned centralis.log in that directory is a
fossil of.
Caddy rejected the config atomically and kept serving prod on the old one, so
nothing broke; but the step reads as a no-op until it isn't.
Revoking PUBLIC's CONNECT on the guest's own database is the half that does not
matter. A fresh Postgres database carries '=Tc' for PUBLIC — TEMP and CONNECT —
so as soon as a second role exists on the instance it can open a session against
every database still holding the default.
Provisioning beta and stopping there left thermograph_beta able to connect to
prod's database. The runbook's isolation check caught it on the live cutover;
this makes the script produce the state that check expects instead of a false
sense of it.
Grants the owner's read-only role an explicit CONNECT before the revoke, so the
ad-hoc query path (ops/dbq.sh, which connects as thermograph_ro) cannot lose
access to prod. The owner's app role owns the database and is a superuser, so it
is unaffected either way.
