Document and preflight Caddy internal CA trust for deployment verification

[fairybladderwort]

Document and preflight Caddy internal CA trust for deployment verification

Context

The production deployment verifier requests https://atlas.home.arpa/up and
https://atlas.home.arpa/status from the deployment host. The intended LAN-only
Caddy configuration uses tls internal for the home.arpa hostname. Caddy's
local CA is therefore not automatically trusted by the deployment host or by
LAN clients.

Without the Caddy route, deployment can fail during the TLS handshake. After
the route is added, an otherwise correct deployment can still fail with a
certificate-verification error if the host does not trust Caddy's local root
CA. The current runbook does not make this prerequisite explicit.

Related work: #54 and #58.

Goal

Make the HTTPS trust prerequisites for atlas.home.arpa explicit and
verifiable for operators deploying ATLAS through the documented Caddy setup.

Required changes

1. Update docs/deployment.md to document that the active Caddy configuration
   must include an atlas.home.arpa site using tls internal and
   reverse_proxy atlas:80 before running the final deployment verifier.
2. Document how to obtain Caddy's local CA certificate from the Caddy data
   volume, and how to install that CA into:
   • the deployment host's OS trust store, because bin/deploy invokes curl
     locally; and
   • each LAN client that will access ATLAS.
3. State clearly that the CA certificate must not be copied into the ATLAS
   repository, .env, Docker build context, application image, or ATLAS
   container.
4. Add a verification sequence covering:
   • Caddy configuration validation and reload;
   • certificate/SAN and TLS verification for atlas.home.arpa;
   • successful /up and /status requests; and
   • bin/verify-deployment succeeding without curl -k or other TLS
     verification bypasses.
5. Add troubleshooting guidance that distinguishes:
   • DNS failure;
   • Caddy not being attached to the external web network or unable to
     resolve atlas;
   • missing atlas.home.arpa Caddy route/certificate; and
   • an untrusted Caddy local CA.

Automation boundary

Do not make deployment scripts automatically install certificates into a host
or client trust store. That is a privileged, host-level security change and
must remain an explicit operator action.

Automation may add a non-mutating preflight check or improve the verifier's
error message so that an untrusted Caddy CA points the operator to the
runbook. It must not weaken TLS verification, set -k, embed the CA in the
application image, or silently modify host trust configuration.

Acceptance criteria

• A new operator can follow docs/deployment.md to configure Caddy's internal
  CA trust before running bin/deploy fresh or bin/deploy update.
• The deployment host's curl trusts the Caddy certificate for
  atlas.home.arpa without -k.
• A LAN client can verify and access both documented endpoints after installing
  the CA through the documented client-specific trust-store procedure.
• bin/verify-deployment passes against the running service.
• No secret or certificate material is committed to Git, .env, the Docker
  build context, the image, or normal application logs.
• Existing deployment and documentation tests continue to pass.