cabal update survives an unreachable Hackage mirror

## Summary

`cabal update` fails when the `objects-us-east-1.dream.io` Hackage mirror is
unreachable, taking the job with it even though `hackage.haskell.org` itself
answered. Make the step survive a dead mirror.

## Motivation

Every default-branch CI failure in the fortnight to 2026-08-29 was this, and
nothing else:

- [Run 32111402964](https://github.com/alunduil/collection-json.hs/actions/runs/32111402964)
(2026-08-18, `main`), GHC 9.6 / macOS — 404.

The failing step is the same in each, and the two lines before the error tell
the whole story:

```
Downloading the latest package list from hackage.haskell.org
Unexpected response 404 for http://objects-us-east-1.dream.io/hackage-mirror/timestamp.json
##[error]Process completed with exit code 1.
```

The primary fetch from `hackage.haskell.org` succeeds. `cabal` then consults
the mirror list the secure repository publishes, tries the dream.io mirror, and
exits non-zero when it cannot read `timestamp.json` there. The response has been
404 on three occasions and 403 on the most recent, so the mirror is failing in
more than one way rather than serving a single stale path.

This is an unowned third-party host — nothing in this repository points at it,
and no change here can make it reliable. A job that cannot install dependencies
because a mirror it never asked for is down is a red board carrying no signal
about the change under review, which is the habit that lets a real failure
through.

It will not clear on its own. Checked 2026-08-29:

```console
$ curl -o /dev/null -w '%{http_code}\n' http://objects-us-east-1.dream.io/hackage-mirror/timestamp.json
403

$ curl -s https://hackage.haskell.org/mirrors.json
… "mirrors":[{"urlbase":"http://hackage.fpcomplete.com/"},
{"urlbase":"http://objects-us-east-1.dream.io/hackage-mirror/"}],"version":13 …
```

The host is still refusing, and Hackage's signed mirror list — version 13, not
expiring until 2027-06-01 — still advertises it. So `cabal` will keep being
handed a dead mirror until Hackage publishes a new list, and the failures will
keep landing on whichever job happens to consult it.

The failures land on unrelated jobs each time (ubuntu and macOS, different GHC
versions, the coverage job), which is consistent with a mirror that is
intermittently unavailable rather than with anything version-specific.

## Scope

- Make `cabal update` tolerate a mirror it cannot reach: retry the step, or
name `hackage.haskell.org` explicitly so the mirror list is not consulted,
or pin the repository configuration so only reachable hosts are listed.
- Whatever is chosen, keep the failure visible when `hackage.haskell.org`
itself is the thing that is down — the point is to stop treating a dead
secondary as fatal, not to make `cabal update` unable to fail.

## Acceptance criteria

- [ ] A `cabal update` run with the dream.io mirror unreachable completes and
the job continues
- [ ] `cabal update` still fails the job when `hackage.haskell.org` is
unreachable
- [ ] Ten consecutive default-branch runs complete with no re-run
- [ ] Pre-commit passes

## Additional context

`alunduil/siren-json.hs` hits the identical failure on its own default branch —
three times in the same fortnight — and carries a sibling issue for it. The two
repositories configure the step differently (siren-json passes `ALLOW_NEWER`,
this one does not), so the fix may or may not be the same text, but the cause is.

siren-json's #144 covers a separate `Update Hackage index` failure mode — ghcup
failing to provision the toolchain — which this repository has not hit in this
window.

Found while triaging default-branch CI failures across repositories for the
fortnight to 2026-08-29.