Allow on-demand certs for the server's own infrastructure hosts

[mechelon]

Why

Follow-up to the on-demand TLS ask endpoint (/expose/can-issue-certificate, added in #14). On a canary deploy it refused the bare server hostname (ap-1.sharedwithexpose.com) and the admin subdomain, because neither is backed by a tunnel — but the wildcard certificate covers *.host, not the host itself, so the server host reaches the on-demand path. The refusal failed the control-connection TLS handshake (ECONNRESET), so clients could no longer connect.

What

• Always allow infrastructure hosts — the server's own hostname and the admin subdomain — mirroring the allows the previous platform ask had. This fixes the canary regression.
• Configurable allow-list — a new optional on_demand_tls.always_allow_hosts config for any additional non-tunnel hosts that should still obtain a certificate (e.g. a status page). Default empty.
• Otherwise unchanged: a certificate is permitted only for a host with a live tunnel.
• Trims the controller doc-comment (the full explanation goes into the SSL docs, handled separately).

// config/expose-server.php
'on_demand_tls' => [
    'always_allow_hosts' => [],
],

Safety

The endpoint stays inert until a Caddyfile points its on-demand ask at it, so merging changes nothing for existing setups. No expose-config switch is required to use the feature; activation lives entirely in Caddy.

Tests

tests/Feature/Server (56 passing), incl. certificate cases: refuse-without-tunnel, allow-with-tunnel, allow-server-host, allow-admin-subdomain, allow-configured-host.