workflow_dispatch on the deploy workflows runs an arbitrary ref with the CM deployment credentials

`workflow_dispatch` lets the caller choose the ref. So *Deploy to Dev / Stage / Prod* can be run against an arbitrary branch, and that branch's own workflow and action YAML executes — with the job's `GITHUB_TOKEN` and, more importantly, with `CLI_TARGET_USERNAME`, `HARPERDB_CLI_TARGET_PASSWORD`, `CLI_DEPLOY_TARGET` and the Datadog key.

### Why this is a smaller problem than #1649, and why it is still a problem

Triggering a dispatch requires **repository write access**, so the `GITHUB_TOKEN` grants nothing its holder does not already have. That is the whole reason it was not folded into #1649, where the event (`merge_group`) is reachable via an approved fork PR from someone with *no* write access.

What remains is a privilege *bridge* rather than an escalation: repository write access reaches the **CM deployment credentials**, which are otherwise not in the repo. Anyone who can push a branch can dispatch a deploy workflow against it and read those secrets out of a step they added. The current controls are that write access is already trusted, and that Actions runs are visible in the run log — not that the secrets are out of reach.

### Options, roughly in increasing order of disruption

- **Assert the ref in the job.** Fail fast unless `github.ref` is the environment's own branch. Cheap, and it means a dispatch against a feature branch cannot deploy — but it is expressed in the dispatched ref's own YAML, so it is regression detection rather than enforcement, exactly like the test in #1649.
- **GitHub Environments with deployment branch policies.** Put the CM secrets on an environment (`dev`/`stage`/`prod`) restricted to that branch. This *is* enforcement: the platform refuses to hand the secrets to a run on a non-matching ref, and it cannot be overridden from the dispatched YAML. Needs the secrets moved from repo scope to environment scope.
- **`repository_dispatch` instead**, which always runs the default branch's workflow definition. Removes arbitrary-ref execution entirely but loses the Run-workflow button, so operators need another entry point.

The middle option looks like the right end state: it keeps the button, and it is the only one that holds even when the dispatched YAML is hostile.

### Provenance

Raised by the cross-model planning review while designing #1649, which wanted it fixed in the same change. Declined there on the fact above — it is a different exposure with a different trust boundary, and bundling a deployment-authorization redesign into a trigger deletion is how the parent PR (#1647) reached twelve review rounds. Filed instead of dropped.

Related: #1649 (merge-queue token, fixed), and the org-level workflow-execution protections noted there — an org-admin setting that would constrain event execution outside candidate-controlled code.

Locate the Deploy to Dev / Stage / Prod workflow definitions and inspect their workflow_dispatch refs and secret usage. Read GitHub Environments deployment branch policies first, then configure dev, stage, and prod so credentials are released only for matching branches while retaining the dispatch button. Done means a non-matching ref cannot receive CM credentials, while an approved environment dispatch still works.

Written by the indexing model from the issue text.