fix(ci): keep nightly pg_cron job production-only

Staging refreshes the materialized views on each deploy (the existing
"Refresh materialized views" CD step), so it does not need the nightly
pg_cron job. Drop ENABLE_PG_CRON from CD_staging.yml; only production
registers the cron job.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: jirhiker

.github/workflows/CD_staging.yml

@@ -55,11 +55,6 @@ jobs:
           CLOUD_SQL_DATABASE: "${{ vars.CLOUD_SQL_DATABASE }}"
           CLOUD_SQL_USER: "${{ secrets.CLOUD_SQL_USER }}"
           CLOUD_SQL_IAM_AUTH: true
-          # Register the nightly pg_cron materialized-view refresh job.
-          # Requires the Cloud SQL instance flag cloudsql.enable_pg_cron=on and
-          # cron.database_name set to CLOUD_SQL_DATABASE. See
-          # docs/pg_cron-nightly-refresh.md.
-          ENABLE_PG_CRON: "1"
         run: |
           uv run --no-dev alembic upgrade head
 

docs/pg_cron-nightly-refresh.md

@@ -36,11 +36,13 @@ Postgres image (`postgis/postgis:17-3.5`) does not do. Running
 
 So the migration is a **no-op unless `ENABLE_PG_CRON` is truthy**:
 
-- Development, test, CI: `ENABLE_PG_CRON` unset → migration prints a skip
-  message and records itself as applied. `alembic upgrade head` works on the
-  stock dev image with nothing extra installed.
+- Development, test, CI, **and staging**: `ENABLE_PG_CRON` unset → migration
+  prints a skip message and records itself as applied. `alembic upgrade head`
+  works on the stock dev image with nothing extra installed. Staging refreshes
+  the views on each deploy instead (the "Refresh materialized views" CD step),
+  so it does not need the nightly job.
 - Production: `ENABLE_PG_CRON=1` → migration creates the extension, the helper
-  function, and the cron job.
+  function, and the cron job. Only `CD_production.yml` sets this.
 
 ## Production setup