Prevent example-suite tooling pins drifting behind the cli_version_sha feature floor

[joshua-temple]

Problem

The fleet dry-run validation surfaced that cascade-example-4env's scenario-suite pins its TOOLING cascade (the setup-cli that drives cascade reset/seed) to a stale release (v0.4.1) predating the node-preserving WriteManifestState (#371) and the cli_version_sha field. That tooling's cascade reset strips cli_version_sha from the manifest, leaving the pin_mode:sha workflows sha-pinned but the field gone, so regeneration drifts the setup-cli workflows and fails the clean drift-check probe + the fail-closed reconcile gate. Only 4env breaks (sole pin_mode:sha lane). This is the #390/#393 class through a new vector (the suite's own reset tooling, not a version-under-test write), activated when #393 restored 4env's sha-pin repin.

The immediate fix bumps the suite tooling pins off v0.4.1. This issue tracks preventing recurrence.

Options (defense-in-depth)

1. A lint/check that every example-suite tooling setup-cli pin stays at or above the cascade feature floor (the lowest release whose state-writer is node-preserving), failing CI if a suite pins below it.
2. Make cascade generate degrade gracefully: when the manifest lacks cli_version_sha but committed workflows are sha-pinned, read the sha back from the committed workflow rather than regenerating a bare tag (so a lossy upstream state-write cannot induce drift).
3. A periodic bump of the suite tooling pins (mirrors the action-pins dependabot anchor pattern).

Option 2 is the most robust (removes the dependency on tooling-version hygiene entirely). Option 1 is the cheapest guard.