feat: self-repin suite to dispatched rc

[joshua-temple]

Problem

The scenario suite always installs the committed cascade CLI pin (v0.8.0), so a fleet run cannot exercise an unreleased rc candidate; every dispatch runs against whatever version is already checked in.

Fix

• Add two optional workflow_dispatch inputs, cascade_version and cascade_version_sha, both empty by default so scheduled and unparameterized runs are unaffected.
• Call stablekernel/cascade/.github/actions/fleet-repin@main in the reset job right after checkout and git identity setup, before the manifest reset, so the checkout it mutates already exists and no state write or dispatch precedes it.
• Forward inputs.cascade_version into the suite's single setup-cli version input, falling back to the committed v0.8.0 pin when no rc is dispatched.
• Add a version-mode log line reporting whether the run is on a dispatched rc or committed defaults.
• Add the missing workflow-level concurrency group (group: scenario-suite, cancel-in-progress: false) so this suite matches the other example repos and cannot overlap runs.

During the migration window the parent repin job is still the only one that executes: a fleet dispatch does not yet pass the new inputs, so fleet-repin no-ops and setup-cli falls back to the committed pin. This suite is unaffected until the parent flips to pass the inputs.

Verification

• actionlint .github/workflows/scenario-suite.yaml passes clean.
• Manual read-through confirms the single setup-cli step, the new concurrency block, and the fleet-repin placement match the migration recipe used across the example-repo fleet.

[github-actions]

Cascade plan preview

This merge would:

• No build or deploy would be triggered by this merge.