fix(admin): say where error reports go, and stop calling a silent target configured

There is no default error-reporting DSN in this tree and there should not be:
a self-hoster's crash reports must not leave their host because nobody told
them not to. That part was already right, so nothing here adds a default.

What was wrong is what the console said about it. The GlitchTip card showed a
green "Configured" badge as soon as a DSN existed, whether or not the switch
that actually sends anything was on, and it never said where reports go. An
operator reading that badge has been told their errors are being collected
somewhere, which may be true of neither half.

The badge now tracks reports actually leaving, and one line under the switch
states the case: the host they go to, or that they stay here, or that tracking
is on with no target. The host only — the public key in the DSN answers a
different question. The deploy runbook says the same thing for a
maintainer-operated instance.

docs/ops/deploy.md

@@ -143,6 +143,18 @@ itself still works: it walks the journey against an in-process instance
 once per leg with that leg broken, and fails if any of them comes back
 green.
 
+## Error reporting
+
+HealthLog ships no default error-reporting target and never will: an
+operator's crash reports must not leave their host because nobody told them
+not to. Reporting starts only when someone types a DSN into **Admin →
+Integrations → GlitchTip**, and that card states plainly whether reports are
+going anywhere and which host they go to.
+
+For a maintainer-operated instance, set the DSN there after the first deploy —
+it lives in the database, not in the environment, so it survives an image
+upgrade and does not need a compose change.
+
 ## Verify the image signature
 
 Every release image (the multi-arch manifest **index**, covering both