docs(website-adr): hosting target Vercel -> Cloudflare via Gitea Actions

Record the deployment decision (2026-06-11): static build deploys to
Cloudflare (Workers static assets or Pages; no Astro adapter needed),
driven by a planned Gitea Actions pipeline. Update the ADR-website-001
index entry to match.

docs/website/adr/20260604-adr-website-001.md

@@ -74,11 +74,17 @@ planning + `/runda` pass with the user and are recorded below.
      and the rusqlite **backup-API** undo (ADR-0006) → a SQL dump/restore.
    When taken up, this becomes its own ADR + iteration plan.
 
-4. **Hosting — portable static build; Vercel is the likely target.** Astro 6
-   builds to static HTML/CSS with no adapter, so the output deploys equally
-   to Vercel, Cloudflare Pages, Netlify, or GitHub Pages. We avoid coupling
-   to any one host. **No CI yet** — the site is tested locally (`pnpm dev` /
-   `pnpm build`) until the repo reaches its public home.
+4. **Hosting — portable static build; Cloudflare is the target (decided
+   2026-06-11).** Astro 6 builds to static HTML/CSS with no adapter, so the
+   output deploys equally to Cloudflare, Vercel, Netlify, or GitHub Pages — we
+   stay uncoupled from any one host. **Planned pipeline: Gitea Actions →
+   Cloudflare.** Cloudflare now steers new projects to **Workers (static
+   assets)** over Pages; either serves the static `dist/` and needs no Astro
+   adapter (the `@astrojs/cloudflare` adapter is only for SSR, which the site
+   does not use). The future in-page WASM playground (§3), if it needs
+   COOP/COEP headers, can get them from Cloudflare `_headers`. **No CI yet** —
+   the site is tested locally (`pnpm dev` / `pnpm build`) until the repo reaches
+   its public home, when the Gitea Actions workflow lands.
 
 5. **Repo topology — monorepo.** The site lives under `website/` in the
    playground repo; the crate stays at the repo root. The repo as a whole