Treat production DOMAINS as a Worker secret and drop keep_vars

[stc93025mn]

Summary

Closed draft #62 committed production DOMAINS into wrangler.jsonc vars. That approach is forbidden in this public repository.

This PR takes the fleet direction (config owns plains; drop keep_vars) without putting the domain list in git:

• Drop keep_vars from wrangler.jsonc and --keep-vars from pnpm deploy:cloudflare.
• Treat production DOMAINS as a Cloudflare Worker secret, not a plain var.
• Declare secrets.required: ["DOMAINS"] so Builds/wrangler deploy fails closed if the secret is missing.
• Keep real domains out of git, wrangler vars, docs examples, and tests. Tests and .dev.vars.example stay on example.com / example.org / example.net.

Runtime is unchanged: src/index.ts still reads env.DOMAINS as a comma-separated string. Secrets bind the same way.

Security floor (unblocks merge)

The org Public Token-Free Security ruleset requires the Security workflow to pass. osv-scanner reported 2 high-severity (≥7.0) groups on fast-uri@3.1.6:

• GHSA-58mr-gqgx-xq4g (7.5) — host confusion via an unclosed bracket in the URI authority
• GHSA-qw65-cvwx-89v3 (7.5) — authority injection via an unvalidated port in serialize

This matches prior security-floor PRs (#61 hono, #59 @humanfs/node, #58 adm-zip): raise the pnpm-workspace.yaml override to the official first-patched 3.x release (fast-uri@>=3.0.0 <3.1.7: 3.1.7) and refresh the lockfile so ajv's transitive fast-uri is 3.1.7. Secrets / keep_vars / README work is unchanged. No real domains. No deploy.

Local osv-scanner after the pin: 0 groups with max_severity >= 7.0. Remaining findings are below the ruleset floor (ip-address 6.9/6.3, qs 6.3, undici 5.9).

Primary user-facing guidance

README.md Production DOMAINS secret is the operator and fork guide:

• Production DOMAINS is a Cloudflare Worker secret.
• Set or rotate via dashboard Settings → Secrets or wrangler secret put DOMAINS.
• Never commit the value. Real domains stay out of this public repo.
• Tests and .dev.vars.example use only example.com / example.org / example.net.

Quick Start, local/dev, deploy, and add/remove-domain sections link to that section. AGENTS.md and CLAUDE.md defer to it.

Why a secret

The one "plain" that would have lived in config is sensitive inventory (which domains this Worker serves). Making it a secret lets us remove keep_vars (unsupported by the cf CLI) without committing the list.

Ops before first Builds deploy after merge

Convert the existing dashboard plain DOMAINS variable to a secret first (see README). Secrets survive deploys; leftover plains do not once keep_vars is gone.

Adding a domain is the same as before, except the list is a secret: update the Worker secret, then dashboard routes and openpgpkey DNS.

Do not set or rotate the secret from GitHub Actions or a Cloud Agent. This PR does not deploy, touch DNS, or use CLOUDFLARE_API_TOKEN.

Docs

No sibling MNPPI Workers used secrets.required; this follows the official Wrangler secrets configuration property so Builds fails closed instead of shipping a Worker that 500s on missing DOMAINS.

Verification

Local checks on this branch (example domains only; no deploy):

• pnpm run format:check — pass
• pnpm run typecheck — pass
• pnpm run lint — pass
• pnpm run coverage — 17/17 tests pass, 100% statements/branches/functions/lines
• pnpm run knip — pass
• pnpm cf:check (wrangler deploy --dry-run) — pass; dry-run reports no config bindings (the secret is not in vars) and does not deploy

Wrangler 4.123 warns that the secrets field is experimental. Tests bind example DOMAINS via vitest.config.ts, so the local-dev "missing required secrets" warning does not fail CI.