chore(infra): delete the GitHub staging keepalive now that the Cloudflare pinger is proven

infra/README.md

@@ -10,7 +10,7 @@ The Render provider reads `RENDER_API_KEY` from the environment. The Cloudflare
 
 The staging web app uses `https://app-staging.useorbit.org`. Keep `staging.useorbit.org` as a custom domain on `orbit-web-staging`; the web proxy redirects requests on that host permanently to the new host. The staging API CORS origins, its Google redirect URIs and the staging upload bucket CORS keep the old host beside the new one, so a tab still running the previous web build keeps working through the cutover. Add the new domain to the live Render service before applying the targeted Terraform changes, and confirm the plan has no update to `render_web_service.staging_web`. Update the `STAGING_NEXT_PUBLIC_SITE_URL` repository variable in `orbit-ui-mobile` to `https://app-staging.useorbit.org`, and add `https://app-staging.useorbit.org/auth-callback` to the Google OAuth web client's redirect URIs. Release the staging API and web from `redesign/main`, then verify the new health route, old-host redirect, email sign-in, and Google authorization.
 
-`staging-pinger.tf` and `workers/staging-pinger.mjs` define the Cloudflare Worker that calls the staging API health endpoint every five minutes from 08:00 through 23:55 in America/Sao_Paulo. See [Staging pinger](#staging-pinger) for deployment, run history, and cutover proof. Keep `.github/workflows/staging-keepalive.yml` until the Worker is deployed and the proof is recorded.
+`staging-pinger.tf` and `workers/staging-pinger.mjs` define the Cloudflare Worker that calls the staging API health endpoint every five minutes from 08:00 through 23:55 in America/Sao_Paulo. See [Staging pinger](#staging-pinger) for deployment, run history, and cutover proof. The Worker is the only staging keepalive.
 
 The reseed workflow checks the Render Postgres creation time daily and replaces the staging database once it is at least 26 days old. A manual dispatch replaces it immediately. The replacement plan is restricted to `render_postgres.staging` and its staging database environment group, and the workflow rejects a plan that changes another resource. For migrations and the owner seed, the workflow temporarily adds the GitHub runner's public IPv4 `/32` to the staging database allow list. It restores and verifies the operator list after each command, including when a command fails. If the reseed job times out, `staging-postgres-access-reconcile.yml` runs independently after completion and on a recurring schedule to remove a tagged runner address. It preserves any other live addresses and fails when those differ from the configured operator list. Between the commands, the reseed workflow triggers an API deploy and waits for that deploy to become live.
 
@@ -85,7 +85,7 @@ Once scheduled invocations are visible, choose an hour entirely inside the windo
 } >> /tmp/orbit-staging-pinger-probes.log 2>&1
 ```
 
-Record all seven timestamp, HTTP status, duration, and exit-code observations in the owning ticket or pull request. Every probe must have a success HTTP status, `curl_exit=0`, and `duration_seconds` strictly below 2. Also record the Worker's intervening invocations at five-minute intervals; the independent probes and retained GitHub workflow can themselves keep the service awake, so probe timings alone do not prove the Worker is running. If any probe fails or the Worker misses an invocation, investigate and restart the full observation hour. Only after both proofs pass does the orchestrator delete `.github/workflows/staging-keepalive.yml` and commit its removal.
+Record all seven timestamp, HTTP status, duration, and exit-code observations in the owning ticket or pull request. Every probe must have a success HTTP status, `curl_exit=0`, and `duration_seconds` strictly below 2. Also record the Worker's intervening invocations at five-minute intervals; the independent probes can themselves keep the service awake, so probe timings alone do not prove the Worker is running. If any probe fails or the Worker misses an invocation, investigate and restart the full observation hour. Run this observation again after any change to the Worker or its schedules.
 
 Provider arguments were confirmed using the installed `cloudflare/cloudflare` 5.26.0 schema. The versioned [Worker script schema](https://github.com/cloudflare/terraform-provider-cloudflare/blob/v5.26.0/docs/resources/workers_script.md) documents `content`, `main_module`, and `observability`; the [Cron Trigger schema](https://github.com/cloudflare/terraform-provider-cloudflare/blob/v5.26.0/docs/resources/workers_cron_trigger.md) requires `schedules`, despite its example using `body`. The controller's `scheduledTime` is milliseconds since the UTC epoch per the [scheduled handler contract](https://developers.cloudflare.com/workers/runtime-apis/handlers/scheduled/). Health response status and success use the [Response contract](https://developers.cloudflare.com/workers/runtime-apis/response/); cache, redirect, and abort options use the [Request contract](https://developers.cloudflare.com/workers/runtime-apis/request/).