Tailnet-only (Serve, no Funnel) compose variants

Three more composes — compose.tailnet.yml, compose.tailnet.frontend.yml,
compose.tailnet.backend.yml — mirror the funnel set exactly but mount
serve.default/frontend/backend.tailnet.json, which drop AllowFunnel. The
sidecar still registers and serves HTTPS with a tailnet certificate, but
nothing is exposed publicly; Serve also needs no ACL change.

Project names carry a -tailnet suffix so both sets can coexist, and the
README explains that each set needs its own data directory (or host), plus
how to switch a host between funnel and tailnet by starting the other file
with the same .env.

Verified: all six composes validate with docker compose config, and the
six serve configs split cleanly into funnel (AllowFunnel present) and
tailnet-only (absent).

AGENTS.md

@@ -34,10 +34,12 @@ Project constraints (do not regress):
 - deploy/ is the deployment source of truth: J621-Frontend (SPA on static
   nginx) and J621-Backend (gunicorn + whitenoise, ffmpeg, migrations on
   start), three compose variants (both / frontend-only / backend-only) behind
-  a shared nginx proxy service, and a Tailscale sidecar per compose whose
-  serve configs only use funnel ports 443 / 8443 / 10000. Images are pushed
-  to the Gitea registry with deploy/push_*.sh (multi-arch, :latest + :sha,
-  GIT_HASH baked in for the version pill).
+  a shared nginx proxy service, and a Tailscale sidecar per compose.
+  serve.*.json are the public Funnel variants (only ports 443 / 8443 / 10000);
+  serve.*.tailnet.json + compose.tailnet*.yml are the same stacks without
+  AllowFunnel (tailnet-only, no public exposure). Images are pushed to the
+  Gitea registry with deploy/push_*.sh (multi-arch, :latest + :sha, GIT_HASH
+  baked in for the version pill).
 - Security/permission tests live in backend/apps/core/tests and need a
   one-time grant: GRANT ALL ON `test_j621`.* TO 'j621'@'%';