fix(release): dispatch the release workflow for a candidate tag

[joshua-temple]

Problem

The orchestrate finalize job cuts the release-candidate tag on the setup head SHA. In steady state that SHA is a prior chore: update state commit whose message carries a CI-skip marker. GitHub evaluates the marker on the tagged commit and suppresses every workflow the tag push would start, so the tag-push trigger that builds and publishes the candidate never fires. Recent candidates (v0.8.0-rc.6/rc.7) produced zero downstream Release runs for exactly this reason; rc.5 only worked because it happened to tag a normal commit.

Fix

When release.workflow is configured and the trunk is dispatch-driven (release_trigger: dispatch), the finalize job now dispatches that workflow explicitly against the candidate tag (gh workflow run --ref), mirroring the promote flow's existing post-publish dispatch. This is the dependable trigger regardless of the tagged commit's message.

• Gated to dispatch-mode trunks so it never races a push-mode trunk's native tag-push trigger (no candidate is built twice).
• Gated to real GitHub (github.server_url) so the act e2e harness, which has no workflow-dispatch API, is unaffected.
• Config-driven and generic: any generated orchestrate benefits by setting release.workflow. cascade's own manifest is wired to its release.yaml and the workflows regenerated.

Verification

go build ./..., go test ./internal/generate ./internal/config (941 pass), golangci-lint run, actionlint on the regenerated workflows (no new findings), and cascade verify (3 files, no drift) all clean. New generator unit tests cover the emit/omit matrix and path normalization.

Notes

Release-path change: warrants a fleet validation run before it is considered fully accepted. This depends on fix/release-trigger-reliability's companion PR #464: the dispatched Release arrives at the fleet as an event: workflow_dispatch source run, which #464's broadened resolve gate must accept to fan the fleet out and produce the version-under-test artifact. Land #464 first (or together); this PR alone would fire the candidate build but the fleet would not validate it until #464 is in.

The regenerated promote.yaml gains the already-specified Trigger Release Build step as a side effect of setting release.workflow; it is guarded on is_final_env and inert for cascade (no environments; final publish runs through the hand-written auto-promote.yaml).