chore(deploy/site): retire the migration scaffolding, keep the health check

The Vercel -> Cloudflare Pages move is done and the Vercel project is
deleted, so the one-shot scripts have no remaining purpose. Nothing in CI
ever called them — deploy-site.yml runs npm ci / test / build / pages
deploy inline — so this removes 10 files and orphans nothing.

Deleted: 00-baseline (refused to run without x-vercel-id, so permanently
unrunnable), 01-preflight (proved Vercel state and API-token scopes),
07-dns-cutover (the phased cutover; in the end the records were attached
through the dashboard, and the rules/apex phases went unused once we chose
APEX_MODE=serve), 09-detach-vercel (its target project is gone), plus
03-ensure-project, 04-set-secrets, 05-deploy, 06-verify-deploy,
02-verify-local and 99-rollback, all either spent or duplicating CI. Their
lib/cf-api.sh went with them: the survivors use wrangler, so the whole
remaining path needs only `wrangler login` and no zone scopes.

What is kept is the part with ongoing value: lib/parity.sh, the assertion
set that caught five real defects during the migration — the live COOP/COEP
bug on the post's canonical URL, the soft-404 Pages would have introduced,
the cross-site form-POST guard Vercel had been providing for free, the
missing immutable header, and HSTS max-age=0. "Does the page return 200"
catches none of those.

08-verify-prod.sh becomes verify.sh, since the numbered sequence it
belonged to no longer exists. It drops the stamp machinery, the dry-run
plumbing and the Vercel-fallback messaging (there is no fallback now:
recovery is promoting a previous Pages deployment), and gains --skip-dns /
--skip-domains so it can be pointed at a single deployment via PROD_BASE
before promoting it.

The README is rewritten around the four invariants that fail SILENTLY —
never widen _headers to /*, keep both URL forms of the Gerber post, never
delete 404.astro, keep the cross-site form-POST guard — each with the
reason, since the reason is the only thing that stops someone simplifying
them back out.

Verified after: 21 probes, 20 pass, 1 warn (HSTS max-age is 6 months vs
Vercel's 2 years — on, just shorter), 0 fail.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LAmkjM7okPdScp9XLW1JVr

deploy/site/lib/parity.sh

@@ -1,11 +1,15 @@
 #!/usr/bin/env bash
-# The one HTTP parity sweep. Sourced by the verify scripts and run against four
-# bases, so "did anything change?" is always the same question:
+# The one HTTP parity sweep. Point it at any base URL and it asks the same
+# question, so a regression has nowhere to hide:
 #
-#   https://www.pcbjam.com                  live Vercel (baseline)
-#   http://127.0.0.1:8788                   wrangler pages dev
-#   https://<hash>.pcbjam-site.pages.dev    the Pages deployment, pre-DNS
-#   https://www.pcbjam.com                  after cutover
+#   https://www.pcbjam.com                  production
+#   https://<hash>.pcbjam-site.pages.dev    a specific deployment, before promoting
+#   http://127.0.0.1:8788                   `wrangler pages dev` locally
+#
+# It was written for the Vercel -> Cloudflare Pages migration and several
+# assertions exist because that migration found real defects; the comments say
+# which, since the reason is the only thing stopping someone "simplifying" them
+# back out.
 #
 # Usage:  assert_parity <base-url> [--scope local|preview|prod] [--live-post]
 # Exit:   0 if every hard assertion passed (warnings do not fail), else 1.
@@ -331,8 +335,8 @@ assert_apex_serves() {
   return $_rc
 }
 
-# APEX_MODE=redirect: apex -> www, path + query preserved. Also used by
-# 00-baseline.sh, since that is what Vercel does today.
+# APEX_MODE=redirect: apex -> www, path + query preserved. Unused with the
+# current `serve` topology; kept in case that decision is revisited.
 assert_apex_redirect() {
   _apex="${1:-$APEX_BASE}"
   section "apex redirect: $_apex"