Publish uploads the exact tarball that was smoke-tested as a candidate

## Summary

The `publish` job publishes a freshly built tarball rather than the bytes that
were uploaded and reviewed as a candidate. Carry the candidate artifact forward
so the published package is the artifact that was verified.

## Motivation

`release.yml:86-93` re-runs `cabal sdist` and then `cabal upload --publish` on
that fresh output. The candidate job at `release.yml:43-50` built its own
tarball earlier. Same tag and same steps, so the two are *probably* identical —
but nothing enforces it, and "probably identical" is the wrong guarantee for an
immutable Hackage upload.

This gets sharper under the release-PR-gated pipeline (#161): once merging the
release PR drives tag to candidate to publish without a second human look, the
candidate stops being a rehearsal a maintainer eyeballs and becomes the only
thing between a merge and an irreversible publish. It has to be the same
artifact.

`cabal upload` offers no promote-an-existing-candidate flag — `--publish`
uploads a package and `TARFILES` is the only input — so promotion means either
re-uploading identical bytes or POSTing Hackage's
`/package/-/candidate/publish` endpoint directly.

## Scope

- Persist the candidate sdist and documentation tarballs as workflow artifacts
from the `candidate` job.
- Have `publish` download those artifacts and upload them instead of rebuilding.
- Alternatively, evaluate POSTing the Hackage candidate-publish endpoint and
drop the second upload entirely.

## Acceptance criteria

- [ ] `publish` does not run `cabal sdist`.
- [ ] The bytes published are byte-identical to the uploaded candidate.
- [ ] A publish run with no corresponding candidate artifact fails loudly rather
than silently rebuilding.

## Additional context

- Piece of the pipeline tracked in #161.