feat: CLI/tool caching in setup-cli action

[joshua-temple]

Problem

Every cascade-owned job that needs the CLI — setup, finalize, preflight, promote, and release — re-downloads the binary from scratch. For a typical orchestrate run with several cascade jobs, that is multiple redundant downloads per pipeline run, adding latency and network load.

actions/cache and the built-in tool-cache mechanism exist precisely for this case. Caching the cascade binary by version hash across jobs in a run (and across runs on the same runner) is a straightforward improvement.

Note: the action ref pinning work (tracked separately) touches the same setup-cli action invocation; coordinate so both land together or the caching work accounts for whatever ref scheme the pinning work settles on.

What to add

Add a cache lookup step to the setup-cli action (or the inline setup step in the generated workflow) using actions/cache:

- name: Cache cascade CLI
  id: cache-cli
  uses: actions/cache@<pinned-ref>
  with:
    path: ~/.local/bin/cascade   # or wherever setup-cli installs it
    key: cascade-${{ runner.os }}-${{ env.CASCADE_VERSION }}

- name: Install cascade CLI
  if: steps.cache-cli.outputs.cache-hit != 'true'
  # ... existing download step

The cache key should include the OS and the resolved CLI version so a version bump or a different OS gets a fresh download. When the version is latest, the key should incorporate the resolved version tag (not the string "latest") to avoid stale cache hits.

Acceptance criteria

• The setup-cli step (or equivalent) checks the tool cache before downloading.
• Cache key includes runner OS and the resolved CLI version.
• A cache hit skips the download step entirely.
• Cache-miss path downloads and installs exactly as today.
• The version resolved from latest is pinned in the cache key (not the string "latest").
• The cached path is added to $PATH whether the cache hit or miss path ran.
• e2e scenario: running the generated orchestrate workflow twice on the same runner results in a cache hit on the second run's setup job, reducing its runtime; the CLI version used in both runs is identical.