One hostname a charger can be told about and actually reach

Charger control needs TLS, and the stack speaks plain HTTP, so the README
said "terminate TLS in a reverse proxy" and left the operator to work out
which four settings have to agree. This adds the proxy: a Caddy overlay
that fronts the Web App BFF — which already carries /api/ and /ocpp/ — so
browsers and chargers arrive at the same name and the certificate is issued
on first boot.

The four settings are derived from DV_DOMAIN, since one value getting typed
right is better odds than four: OCPP_PUBLIC_URL, OCPP_REQUIRE_TLS back on,
CORS, and TRUST_FORWARDED_PROTO on the Web App. That last one is the
non-obvious one — without it the BFF overwrites Caddy's X-Forwarded-Proto
with its own plaintext hop and the API Server rejects the charger it just
told to connect over wss.

The README's OCPP section was stale besides: it still sent chargers to the
API Server port alone, from before the BFF carried that path.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Docker/.env.example

@@ -66,3 +66,11 @@ VITE_API_BASE=
 #   CORS_ALLOW_ORIGINS  browser origins allowed to call the API Server directly.
 # POCKETBASE_URL=http://pocketbase:8070
 # WEBAPP_URL=http://web-app:8090
+
+# --- Public hostname + TLS (docker-compose.tls.yml) --------------------------
+# Only read when the TLS overlay is layered on. DV_DOMAIN must resolve to this
+# host from the internet, with ports 80 and 443 reaching it; the certificate is
+# issued automatically on first boot. Setting it also points chargers at
+# wss://DV_DOMAIN, which is what lets OCPP_REQUIRE_TLS stay on.
+DV_DOMAIN=
+DV_ACME_EMAIL=