promote-latest: a SemVer with both a prerelease and build metadata is rejected #374

scripts/promote-latest.sh rejects a valid SemVer carrying both a prerelease and build
metadata. Found by CodeRabbit on cli#371 @ 0b1fb8c6; verified before filing, not relayed:

1.2.3                 -> proceeds to the existence check
1.2.3+build-abc       -> proceeds
1.2.3-rc.1            -> proceeds
1.2.3-rc.1+build-abc  -> promote-latest: invalid version

Cause

scripts/promote-latest.sh:204

if ! [[ "$version" =~ ^[0-9]+\.[0-9]+\.[0-9]+([-+][0-9A-Za-z.-]+)?$ ]]; then

One optional suffix group, and its character class contains - but not + — so after
-rc.1 a +build cannot match. SemVer permits both, in that order.

Fix (one line, written down so nobody re-derives it)

Separate optional groups:

^[0-9]+\.[0-9]+\.[0-9]+(-[0-9A-Za-z.-]+)?(\+[0-9A-Za-z.-]+)?$

Extend fixture Q in scripts/test-promote-latest.sh to cover 1.2.3-rc.1+build-abc: it must
validate, be treated as a pre-release (so it still requires --allow-downgrade), and promote
all six. The existing Q case asserts build-metadata-only is treated as stable; both must hold.

Why this was deferred rather than fixed in #371

Deliberate, and recorded so it is not mistaken for an oversight. #371 ran four rounds, each
finding something real. This is a Minor affecting a version shape our release flow does not
produce — every published version is plain X.Y.Z — and each additional round costs two reviewer
turns on a shared, capped inference account. The gap is unreachable in our actual usage, the fix
is known and written above, and promote-latest.sh cannot run for real until the six Trusted
Publisher registrations exist (cli#370), so this lands well before first use.

If someone touches that validation for any other reason, fix this in the same commit.

Refs #366