CI provisions the GHC toolchain without needing re-runs

## Summary

`haskell-actions/setup` intermittently fails to provision the GHC toolchain,
failing jobs in the matrix and forcing manual re-runs.

## Motivation

Every observed failure is inside toolchain provisioning, before any project
code compiles:

- Run 32111597666 (2026-08-18, `main`), GHC 9.14 / ubuntu — ghcup warned that
cabal 3.16.1.0 "has shadowed binaries", step exited 1.
- Run 31888410463 (2026-08-15, `main`), GHC 9.10, 9.6 and 9.8 / ubuntu —
`[GHCup-00130] The version '9.10.3' of the tool ghc is not installed`.
- Run 32172963969 (2026-08-18, #143), GHC 9.6 / macOS —
`Unexpected HTTP response: 503`. Green on the third attempt.
- Run 32176318932 (2026-08-18, #143), GHC 9.10 / macOS — same 503. Green on the
second attempt.
- Run 32187403568 (2026-08-19, #143), GHC 9.6, 9.10 and 9.14 / macOS — same 503
on all three at once, then 9.6 and 9.14 again on re-run. Green on the third
attempt.

Two distinct failures are mixed together here. The 503 is a fetch against the
toolchain host and has only ever been seen on macOS, where it hit three jobs
simultaneously in the most recent run — that looks like an upstream outage
window rather than per-job bad luck, and it is the one that costs repeated
re-runs. The ubuntu failures are different: ghcup reporting a version it just
installed as missing, and the cabal shadowed-binaries exit, neither of which is
a network symptom.

Because the affected jobs move around, a red board carries no signal about the
change under review. The natural response is to re-run rather than to read it,
which is the habit that lets a real failure through.

## Scope

- Cache the GHC installation. The cabal store is already cached in `ci.yml`; the
toolchain itself is fetched on every job, which is what the 503 hits.
- Retry the setup step for the transient class, or pin to a toolchain source
that isn't a single point of failure on macOS.
- Diagnose the ubuntu failures separately — the shadowed-binaries exit and the
"not installed" error look like a ghcup/cabal interaction, not a fetch
problem, and caching won't address them.

## Acceptance criteria

- [ ] Ten consecutive `main` runs complete with no re-run.
- [ ] A transient toolchain fetch failure retries instead of failing the job.
- [ ] The ubuntu ghcup failures are diagnosed, and either fixed here or shown to
be upstream and tracked there.

## Additional context

Surfaced while reviewing CI on #143, whose three commits are workflow and
documentation only — the last contains no executable change at all, and still
needed three attempts to go green. That is what makes the flakiness clearly
pre-existing rather than introduced.

No milestone: this doesn't advance the 1.0.0.0 API commitment, though it does
make the release CI trustworthy.

Start with ci.yml and the jobs invoking haskell-actions/setup; compare the listed Ubuntu and macOS runs with their setup logs. Check how the existing Cabal cache is configured, then separate the 503 fetch failures from the Ubuntu ghcup and shadowed-binaries failures. Done means transient fetches retry, Ubuntu failures are fixed or tracked upstream, and ten consecutive main runs pass without re-runs.

索引モデルが issue の本文から書いたものです。