fix: do not let a stale cache directory suppress signature verification

[cpanato]

ct.sh treated the existence of the cache directory as proof that a
verified install had happened, and interpolated unvalidated version
strings into filesystem paths and into $GITHUB_PATH / $GITHUB_ENV.
Three related problems followed from that.

1. mkdir -p "${cache_dir}" ran before the download and verification,
   so a run that failed verification left an empty directory behind.
   Every later run on the same runner then took the cache-hit path,
   skipped cosign entirely, and executed whatever was at
   ${cache_dir}/ct.

2. Because ${version} was interpolated straight into cache_dir, a
   value containing ../ resolved outside $RUNNER_TOOL_CACHE
   altogether. Pointing it at an existing attacker-controlled directory
   made the cache-hit path fire on the first run: cosign was never
   invoked, the script exited 0, and that directory was prepended to
   $GITHUB_PATH for every subsequent step.

3. A newline in a version string added extra lines to the
   $GITHUB_ENV file, which the runner parses one KEY=VALUE per
   line, allowing arbitrary environment variables (LD_PRELOAD, say)
   to be set for later steps.

Fixes:

• Validate all three version inputs against a strict version pattern,
  rejecting path separators and newlines at the point of entry.

• Gate the cache-hit path on [[ ! -x "${cache_dir}/ct" ]] rather than
  on the directory existing, so a partially populated cache no longer
  counts as a verified install.

• Download, verify and extract into a mktemp -d staging directory and
  publish to ${cache_dir} only once all three succeed, with an EXIT
  trap removing the staging directory on every path. A failed run now
  leaves nothing behind that a later run could reuse.

• Add --fail to the download so an HTTP error is reported as a
  download failure instead of being saved as the "tarball" and
  resurfacing as a misleading signature-verification error.

Residual, and accepted: an executable ct pre-seeded at the validated
cache path still short-circuits verification. That requires write access
to $RUNNER_TOOL_CACHE, which means code already running on the runner,
and it is the same trust model the actions/setup-* tool cache uses.

Verified with a harness using fake curl/cosign/uv:

• traversal version -> rejected, exit 1 (was: exit 0, cosign never
  invoked)
• newline version -> rejected, exit 1, $GITHUB_ENV untouched
• empty cached dir -> cosign now invoked and install completes
  (was: exit 127, cosign never invoked)
• failed verification -> exit 1, zero entries left under the tool cache,
  $GITHUB_PATH untouched, no staging dir leaked
• clean install -> exit 0, correct $GITHUB_PATH, ct version runs
• unknown version -> "Unable to download", not "Unable to validate"

shellcheck, bash -n and zsh -n all clean.