feat: allow release-candidate versions in the release pipeline

[webern]

Human Summary

Allows a suffix to be added to a release version and tag.

Summary

Release-candidate versions like 0.6.0-rc1 were rejected. release-build validated its version input against three plain numbers, so a candidate never got past the first job.

Two changes make one work:

• release-build validates the version as SemVer 2.0 with the optional pre-release suffix. Build metadata (+meta) is still rejected, because SemVer ignores it when comparing versions, so two releases differing only there would look like one version to a consumer.
• release-publish passes --prerelease to gh release create when the version carries a suffix. The repository's latest release keeps pointing at the newest finished version, and a candidate is never the default download. The release PR body now says the same thing to whoever reviews and tags it.

Nothing else needed to change. The v* tag trigger, the six publish checks, the asset URL and the two-commit PR shape were already written in terms of the version string rather than its shape, so they took a candidate as-is.

A consumer reaches a candidate by pinning it:

.package(url: "https://github.com/webern/mx.git", exact: "0.6.0-rc1")

Section 7 of docs/ai/design/release-process.md covers the ordering rules, what publishing does differently, and that pinning line. The revision log has a new entry (d).

Testing

This is workflow YAML, so it was verified locally rather than on a runner.

• Both workflows parse as YAML, and every run script passes bash -n
• The validate job's regex, extracted from the workflow and driven directly, over 23 versions. Accepted: 1.4.0, 0.6.0-rc1, 0.6.0-rc.1, 0.6.0-alpha.beta.1, 1.0.0-0, 1.0.0-x-y-z.0. Rejected: v0.6.0-rc1, 0.6.0-, "0.6.0-rc 1", 0.6.0+build, 01.2.3, 0.6.0-01, 0.6.0.1, 0.6.0_rc1, empty, and a two-line string
• The git-lifecycle simulation from feat: add a binary swift release pipeline #418 re-run end to end with version 0.6.0-rc1: branch release-prep/v0.6.0-rc1, tag v0.6.0-rc1, the B and R commit shape, publish checks 1 through 4, the baked asset URL and checksum, and the squash-merge recovery path all behave the way they do for 1.4.0
• The same simulation still passes for 1.4.0
• Both sides of each new conditional: --prerelease present for 0.6.0-rc1 and absent for 1.4.0; the PR body note appears for a candidate, and its placeholder line is removed for a final release

Not covered locally: the macOS build itself and the real gh calls. Those first run when a release is dispatched.

References

• Follows feat: add a binary swift release pipeline #418, which built the release pipeline