Guard the Pages publish step against transient deploy-pages failures

## Context

The `publish` job in `.github/workflows/pages.yml` failed once on a scheduled
run with a transient GitHub-side TLS error inside `actions/deploy-pages@v5`:

```
##[error]Creating Pages deployment failed
##[error]HttpError: self-signed certificate; if the root CA is installed
locally, try running Node.js with --use-system-ca
at createPagesDeployment (.../deploy-pages/.../api-client.js:125)
```

Failed run: https://github.com/alunduil/blog.alunduil.com/actions/runs/31549970122
(run #560, `schedule`, 2026-08-12 00:22 UTC).

The build job succeeded and uploaded the `github-pages` artifact; only the final
deploy API call failed. The certificate is served by GitHub's own Pages
deployment endpoint — nothing in this repo influences it, so this is an
infrastructure blip, not a config bug.

## Why it's worth a small guard

The failure is isolated and self-healing: every run before #560 and the two
scheduled runs after it (#561, #562) succeeded and redeployed the same `main`
head, so no content was actually lost. Given the 6-hour cron cadence, a single
transient failure is picked up automatically by the next run.

The residual risk is narrow: a transient `deploy-pages` failure on a run that
matters more than the cadence tolerates — notably the `50 7 * * *`
Europe/London cron that reveals date-gated posts at ~08:00. If that specific run
hits the blip, publication of a scheduled post slips to the next 6-hourly run
(~12:00 London) unless someone re-runs it by hand.

## Proposed change

Add a lightweight retry around the single `deploy-pages` step so a one-off API
hiccup self-recovers within the same run instead of waiting for the next cron.
Options, smallest first:

- [ ] Wrap the step with a retry action (e.g. `nick-fields/retry`), pinned by
SHA per the repo's action-pinning + Renovate convention, with a couple of
attempts and a short backoff.
- [ ] Or add a hand-rolled retry loop as a small `run:` step calling the Pages
deploy API — heavier, loses the maintained action, probably not worth it.

Scope is the `publish` job only; the `build` job and the rest of the workflow
are unaffected.

## Acceptance criteria

- [ ] A single transient `deploy-pages` failure retries within the same workflow
run rather than failing the job outright.
- [ ] Any new action is pinned by commit SHA and picked up by the Renovate
config, matching the existing entries in `pages.yml`.
- [ ] `actionlint` (via the pre-commit suite) passes on the edited workflow.

## Notes

Deferred here rather than fixed inline because it's a hardening nice-to-have
against a rare, self-healing condition, not a live breakage — see the
diagnosis of run #560 above.