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.