ci: SHA-pin the four unpinned actions in pages.yml (missed the #123 merge)

[hyperpolymath]

Follow-up to #123. This is the one commit from that branch that missed the merge —
#123 was squash-merged at head 120f32d (12:06 UTC); this commit was authored at
12:17 UTC, ten minutes later, so it was never part of the PR and never ran CI.

Main is red on governance / Workflow security linter today purely because of it.

What this fixes

pages.yml was dropped in by the Ddraig SSG mass-rollout (#121) without this repo's
SPDX and SHA-pinning conventions. #123 fixed the missing SPDX header — and that is
exactly what exposed this second defect: the linter exit 1s immediately after its
SPDX/permissions block, so the pin check downstream had never been reached.

ERROR: Found unpinned actions:
  .github/workflows/pages.yml:25  actions/checkout@v4
  .github/workflows/pages.yml:27  actions/checkout@v4
  .github/workflows/pages.yml:44  actions/upload-pages-artifact@v3
  .github/workflows/pages.yml:57  actions/deploy-pages@v4

The SHAs are copied verbatim from casket-pages.yml — the active, already-compliant
Pages workflow in this repo — rather than freshly resolved, so the two Pages workflows
converge on one vetted set instead of diverging into a third.

Side effect worth naming: this also moves upload-pages-artifact v3→v5 and
deploy-pages v4→v5, which is what makes them consistent with casket-pages.yml.
pages.yml is disabled_manually, so there is no runtime risk today — we are
unblocking a linter on a workflow that does not currently run.

Verified locally (reproducing the linter's own grep)

PASS: all root actions SHA-pinned
(no root workflow missing an SPDX header)
all root workflows parse OK

Expected CI on this PR — please read before judging the tick

governance / Workflow security linter → should go green.

governance / Check Workflow Staleness → will stay red, by design. It is
independent of this change and was already failing on main before #123 existed. Its
three errors are all standards-reusable pin staleness (d7c22711e830, 59 commits / 24d
behind 8813ecf2a841). That refresh is shared across ~54 callers and coordinated
centrally, and there is a standing estate finding that consumers should not be re-pinned
yet. Left to that effort deliberately.

So the Governance workflow will still report failure on this PR. That is the
staleness job, not this fix. Do not read it as "the pin fix didn't work" — check the
per-job conclusions.

Also settled while verifying: the staleness job's "Remove legacy scorecard-enforcer.yml"
line is its generic remediation summary, printed on any failure — not a path
detection. The only copy of that file is in the inert aletheia/.github/workflows/, and
nothing is reaching into it. No action needed there.

🤖 Generated with Claude Code