feat: external-signal trigger for the rollback workflow

[joshua-temple]

cascade already generates a rollback workflow that re-deploys a prior version or SHA to a
target environment, defaulting to the previous version, triggered by manual dispatch. What
is missing is a way for an external monitor (for example a rollout controller
or any alerting system) to trigger that same rollback automatically by firing a
repository_dispatch event.

Add an opt-in repository_dispatch trigger to the generated rollback workflow that maps
the event payload onto the existing environment and target inputs, so an external signal
can drive the same N-1 rollback the manual path already performs.

This is the GitHub-native alternative to running a separate auto-rollback controller: the
rollback logic stays in the generated workflow and external systems only need to fire a
dispatch.

Proposed approach:

• Add an opt-in manifest flag (for example under the rollback configuration) that wires a
  repository_dispatch trigger onto the generated rollback workflow.
• Map the dispatch payload fields (environment, optional target, optional deployable) onto
  the inputs the workflow already accepts.
• Keep workflow_dispatch as-is so the manual path is unaffected, and keep the trigger
  absent by default.

Acceptance criteria:

• With the opt-in absent, the rollback workflow is byte-for-byte unchanged
  (workflow_dispatch only).
• With the opt-in enabled, the generated workflow also accepts a repository_dispatch
  event and resolves the same target the manual path resolves.
• The payload mapping is documented, including which payload keys map to which inputs.
• An e2e scenario fires a dispatch and asserts the rollback re-points the target
  environment to the prior deployment.