fix(release): actually create a GitHub Release per successful build

[github-actions]

Which case is it

None of (a)-(d) as stated — the release/tag-creation code never existed at all. This isn't a step that fails, is skipped, or no-ops silently; there was no git tag / gh release create anywhere in the repo to begin with. Grep confirms it:

$ grep -rln "git tag\|gh release create\|GH_RELEASE_PAT" .github/workflows/ .
(no matches anywhere in the repo)

Evidence

• gh api repos/izzywdev/FuzeAgent/releases/latest → 404
• gh api repos/izzywdev/FuzeAgent/tags → []
• gh api repos/izzywdev/FuzeAgent/releases → []
• .github/workflows/release.yml ("Release (images + GitOps bump)") does run, and does succeed — e.g. run 32779840396 (success, 2026-08-24). Its job log for build-and-bump shows the full sequence completing: images built/pushed, values-prod.yaml bumped, branch pushed, and — proven by the automatic git fetch/fast-forward of main that gh pr merge performs only after a merge actually lands — the GitOps bump PR created, approved, and admin-merged, using GH_APPROVE_TOKEN. That secret is set and works; it is not the "GH_RELEASE_PAT unset" failure mode this fleet has hit elsewhere.
• Confirmed independently via gh api repos/izzywdev/FuzeAgent/pulls?state=closed: PRs release: fuzeagent images 98b9b314bb0d #193, release: fuzeagent images 5772f14a7a75 #186, release: fuzeagent images 4d4903aa3103 #183, release: fuzeagent images a77aab6a8de6 #180 titled release: fuzeagent images <sha> all show a real merged_at timestamp.
• So the workflow is a working CD/GitOps image-bump pipeline (build images → push to GHCR with a SHA tag → bump Helm values → self-merge). It was just never a release/versioning pipeline — nothing in it, or anywhere else in the repo (no VERSION, no CHANGELOG, no semver tooling), ever created a git tag or a Release object. "Release" in the workflow's name describes the deploy, not a GitHub Release.

What I changed

Added one step to the end of the existing build-and-bump job in .github/workflows/release.yml: after the images are built and the GitOps bump PR is merged, create a GitHub Release tagged release-<short-sha> (the same short SHA already used for the image tags), with notes listing the five images published in that run.

• Uses the job's existing default GITHUB_TOKEN (contents: write, already granted) — creating a tag + Release via the API never pushes to the protected main branch, so it needs no elevated token and no new secret.
• No masking: nothing added here (or removed) uses || true / continue-on-error. If gh release create fails, the job fails, visibly.
• Validated with actionlint and a YAML parse — both clean.

What remains / owner action

None required for this to start working. No secret needs to be added or rotated — the fix only relies on the token and permissions the job already has. Once this PR merges, the next push to main touching one of release.yml's watched paths will produce the first-ever entry in gh api repos/izzywdev/FuzeAgent/releases.

One open judgment call left to the owner, not a blocker: the tag scheme here is release-<image-sha> (traceability to what was built), not semantic versioning — there's no VERSION file or conventional-commit tooling in this repo to derive a semver bump from. If the owner wants real semver releases instead, that's a separate, larger design decision (parsing commit history / a version file) and is out of scope for "make the release step actually create a release."