fix(helm-deploy-eks): makeLatest legacy → true (legacy semver broken on rc tags)

[pdodgen-revparts]

Follow-up to #155. Tested legacy against encodium/batch rc.9 vs rc.12 today — it did NOT re-designate. Diagnosis:

GH's semver comparator treats 2026-07-09 in the prerelease identifier as an alphanumeric segment (hyphens present), then compares subsequent segments incorrectly. So -rc.2026-07-09.12 does not rank above -rc.2026-07-09.9 in GH's implementation.

Verified: PATCH with make_latest: legacy → rc.9 stayed latest. PATCH with make_latest: true → rc.12 became latest.

Semantic change

• Before (legacy): GH re-evaluates via semver. Broken for our tag shape.
• After (true): every successful prod deploy re-designates as latest.

Rollback behavior changes: under true, rolling back to an older rc makes THAT rc latest (accurately reflecting what's live). Under legacy we'd have kept the newer rc as latest despite older code running. true is the more useful semantic during incidents.

Not affected

• Main-branch clean tags (vX.Y.Z) go through mathieudutour/ncipollo on release CREATE, not PATCH. Normal semver ordering applies there — no impact.

[cursor]

PR Summary

Low Risk
CI-only change to GitHub release metadata after prod deploys; no runtime or auth impact, with intentional rollback semantics for the “latest” label.

Overview
Prod deploys that PATCH GitHub releases via ncipollo/release-action now pass makeLatest: true instead of legacy, so each successful promotion re-marks that tag as GitHub’s “latest release.”

Comments document why legacy failed for RT v2 rc tags (hyphenated prerelease segments break GitHub’s semver comparison) and why omitting the field still leaves an old rc pinned. Rollback behavior shifts: deploying an older rc will move “latest” backward to match what’s actually in prod. Clean vX.Y.Z releases created elsewhere are unchanged.

^{Reviewed by Cursor Bugbot for commit 39c1dfa. Bugbot is set up for automated code reviews on this repo. Configure here.}