ZephyrAB web surfaces — how to serve these three files
=======================================================

This package installs FILES, not a web server. Each is one self-contained
HTML document: no build step, no CDN, no external fetches. What matters is
WHERE each is served, because the placement rules are security properties,
not taste. Every one of them was learned on a live deployment.

mail.html — the webmail (JMAP client, RFC 8620/8621)
----------------------------------------------------
Serve it on the SAME ORIGIN as the JMAP endpoint (/jmap), IMAP-independent.
The page's own CSP restricts connect-src to 'self', so served anywhere else
it cannot reach the API at all — that restriction is deliberate (a mail
client that can talk to a third-party origin can leak a mailbox), so front
it correctly rather than weakening the policy.

Suggested Caddy shape, on the mail hostname that already proxies /jmap:

    handle /mail* {
        rewrite * /mail.html
        root * /usr/share/zephyrab/www
        file_server
        header Content-Security-Policy "default-src 'none'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; connect-src 'self'; img-src 'self' data:; form-action 'self'; frame-ancestors 'none'"
    }

mail-ai.html — the writing-assistant frame
------------------------------------------
A SEPARATE document with its OWN CSP, never inlined into the mail page. The
webmail embeds it sandboxed (allow-scripts, no allow-same-origin) so a
user's bring-your-own-model key and prompt bytes can reach the model's
origin and nothing can reach the mailbox. Serving it under the mail page's
CSP breaks the client-direct mode outright; serving it without a sandbox
would let it read the mail page's DOM. Serve at /mail-ai on the same host:

    handle /mail-ai* {
        rewrite * /mail-ai.html
        root * /usr/share/zephyrab/www
        file_server
    }

console.html — the admin console
--------------------------------
The ADMIN origin, never the mail host. It drives /admin/api (OAuth2), and
the deployment this was built on serves it from the apex while the mail
hostname deliberately answers /admin/* with a redirect away — an admin
control plane on the same origin users type their mail password into is a
phishing surface nobody needs. Keep the two apart:

    zephyrab.example {                # the admin/apex origin
        handle /console.html { root * /usr/share/zephyrab/www; file_server }
        handle /admin/api* { reverse_proxy 127.0.0.1:8080 }
    }
    mail.zephyrab.example {           # the mail origin: NO /admin proxy
        ...
    }

Upgrades
--------
dpkg owns these files; do not edit them in place (an upgrade replaces them).
Local changes belong in your proxy layer, or copy the file elsewhere and
serve the copy — and know that a copy no longer upgrades.
