feat: merge-queue (merge_group) validation lane

[joshua-temple]

Problem

Trunk-based orgs increasingly use GitHub merge queues. The merge_group event runs against the would-be-trunk commit immediately before it lands. cascade currently has no way to emit a lane that validates that prospective trunk state with its own logic, so the merge queue can only run whatever generic checks the user wires up by hand.

Proposal

Emit an optional merge_group-triggered lane that runs cascade's validate (and dry-run build) callbacks against the merge-queue candidate ref, so the commit about to become trunk is checked with the same logic that will orchestrate it post-merge.

This is trunk-integrity, not PR-CI: it gates the transition into trunk, which is squarely cascade's domain. It is read-only (no state writes, no releases, no deploys), opt-in, and self-contained.

Schema sketch

# manifest.yaml (top-level)
merge_queue:
  enabled: true

Acceptance criteria

• cascade generate-workflow emits a merge_group lane when enabled (opt-in, non-breaking when omitted).
• The lane runs the configured validate/build callbacks in dry-run against the merge-group ref and reports a status the queue can require.
• No state, release, or deploy side effects occur.
• e2e scenario: a merge_group event triggers the lane and reports pass/fail based on the dry-run callbacks.

Related: the additional-triggers work (schedule / repository_dispatch / workflow_run) and the PR plan-preview / manifest-validation issues.