The web UI's certificate from Let's Encrypt, through Jarl

tls.acme names the certificate and jarl: the Jarl server and a token that
may only write the challenge record. Steward gets the certificate with
DNS-01 (lego), writing the record through Jarl's API into every view that
has the zone, renews it with a third of its lifetime left and swaps it
in without a restart. A check runs before every order: Jarl, the zone,
the token's permission, a test record, the zone's name servers, public
resolvers, clean-up; each step says what to fix. Staging by default.

With a certificate, each listener serves HTTPS and plain HTTP on one port
(redirecting plain HTTP, except from the server itself).

steward cert / cert check / cert renew, Server -> Certificate in the web
UI, GET /certificate, POST /certificate/check|renew. docs/certificates.md
and docs/jarl.md (the Jarl user and the token's grant).

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

AGENTS.md

@@ -19,6 +19,11 @@ When in doubt, do it the way Jarl does. Go module `steward`,
   result, saves the objects and a history entry in one transaction, then
   hands the new state to the DHCP server. Never write subnets,
   reservations or settings to the store from a handler.
+* **The web UI's certificate** (`internal/certs`, with `internal/jarl` for
+  Jarl's API) is obtained through lego, with Jarl publishing the
+  DNS-01 challenge. A preflight check runs before every order. Test it
+  against Jarl's e2e environment (`KEEP=1 PEBBLE=0 scripts/e2e.sh` in
+  `../jarl`) with Pebble pointed at its named (docs/development.md).
 * **Leases are not configuration.** `dhcpd` owns them: kept in memory, and
   written to the store (`PutLease`) before the ACK is sent. They are not
   in the history.