ci: unbind the Dagster deploy from the production environment

[jirhiker]

Settings change, already applied

The production GitHub environment now requires review from the deployers
team, with self-review prevented:

{"type":"required_reviewers","reviewers":["deployers"],"prevent_self_review":true}

So applying a data migration to production takes two people. Irreversibility is
the reason — a migration that deletes rows has no downgrade, only a restore.
deployers has four members, so requiring a second person will not deadlock.

Why this code change goes with it

That environment is shared by three workflows. The gate now also covers
production API releases (CD_production.yml), which is intended: release-please
already makes releasing a decision, and this adds one approval to it.

It would also have covered CD_dagster_prod.yml, which is not intended.
That job reads only repository-level DAGSTER_CLOUD_API_TOKEN and
DAGSTER_CLOUD_ORGANIZATION_ID — none of the environment's secrets — and since
it was retargeted it runs on every push to staging touching the code
location. Binding it would have put an approval gate on routine merges: a gate
on the wrong thing, since it publishes code rather than data.

Verified before removing it that the job consumes nothing environment-scoped.
The environment's own secrets (CLOUD_SQL_*, deploy service account keys,
SESSION_SECRET_KEY) remain in use by the two workflows that need them.

Effect

workflow	gated now?
Data Migrations → production	yes
CD_production.yml (API release)	yes
CD_dagster_prod.yml (code location)	no
Data Migrations → staging	no

🤖 Generated with Claude Code

[github-actions]

Coverage

✅ 77.96% total — gate is 75%.