ci: unbind the Dagster deploy from the production environment

The `production` GitHub environment now requires review from the deployers
team, with self-review prevented, 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.

That environment is shared, so the gate also covers production API releases,
which is intended -- release-please already makes releasing a decision, and this
adds one approval to it.

It would also have covered the Dagster code location deploy, 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 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.

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

Author: jirhiker

.github/workflows/CD_dagster_prod.yml

@@ -47,7 +47,13 @@ concurrency:
 jobs:
   dagster-prod-deploy:
     runs-on: ubuntu-latest
-    environment: production
+    # Deliberately not bound to the `production` GitHub environment. This job
+    # reads only repository-level DAGSTER_CLOUD_API_TOKEN and
+    # DAGSTER_CLOUD_ORGANIZATION_ID -- none of that environment's secrets -- and
+    # it runs on every push to `staging` that touches the code location. Binding
+    # it would put an approval gate on routine merges once `production` requires
+    # reviewers, which is a gate on the wrong thing: this publishes code, not
+    # data.
 
     steps:
       - name: Check out source repository