docs: hiding the site also hides the login page, and that has a consequence

The gate exempts admin/* so the console keeps working, but /admin sends a guest
to /login and /login is not the console — so with the site hidden and no VPN
yet, an operator cannot sign in to flip the switch back. Found while bringing
up the live server.

The mechanism for it already exists and is the right one: TRUSTED_RANGES. What
does NOT work is exempting the login flow by hostname, which was the obvious
patch — a Host header is chosen by the caller, so one forged header would have
lifted the gate for every route, portal included. Codex caught that; the comment
now says why the narrow-looking option is the wrong one.

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

app/Http/Middleware/PublicSiteGate.php

@@ -31,6 +31,14 @@ class PublicSiteGate
      * able to drive portal components — including billing — while the portal is
      * supposed to be offline. Operators pass the check below anyway, which is
      * what the console actually needs.
+     *
+     * Nor is /login, and that has a consequence worth knowing before you hide
+     * the site: /admin sends a guest to /login, which is not the console, so
+     * SIGNING IN while hidden needs the request to come from a trusted range —
+     * the management VPN, or an address put in TRUSTED_RANGES for the initial
+     * setup. Exempting the login flow by hostname instead would mean trusting a
+     * Host header, which the caller chooses, and one forged header would unhide
+     * the entire portal.
      */
     private const ALWAYS_ALLOWED = ['admin', 'admin/*', 'webhooks/*', 'up', 'robots.txt'];