docs: correct release process to match deployed Prow config

[aevyrie]

The previous ## Release Process section described a draft-release postsubmit on push to main producing a v{version}-tagged draft. That job is not deployed. The actual publish trigger in fslabs-infra (modules/ci/prow/terragrunt.hcl) is a publish-all postsubmit on branches matching ^cargo-fslabscli-\d+\.\d+\.\d+$, which runs fslabscli publish and creates the tag as cargo-fslabscli-{version}.

This PR rewrites the section (steps + Mermaid diagram) so it matches what actually runs.

[fslabs-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from aevyrie. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[loispostula]

Correcting my earlier version of this comment, which had the history backwards.

You were right. At the time you opened this, the deployed job genuinely did not match the README. The fslabscli entry in modules/ci/prow/terragrunt.hcl read:

branches    = ["^cargo-fslabscli-\\d+\\.\\d+\\.\\d+$"]
tag_pattern = "cargo-fslabscli-.*"

with no job_name (so it fell through to the publish-all default), no tag_format (so it fell through to the {package_name}-{version} default, giving cargo-fslabscli-{version}), and no draft block at all, so draft-release was not deployed. Your description of the deployed behaviour was accurate on every point.

What changed is that the job got fixed rather than the docs. That landed in infra on 2026-07-28, and the entry now reads:

job_name    = "publish-release"
branches    = ["^v\\d+\\.\\d+\\.\\d+$"]
tag_pattern = "v.*"
tag_format  = "v{version}"
draft = {
  enabled       = true
  branches      = ["^main$"]
  publish_steps = "nix,github"
}

So draft-release is deployed on ^main$, the tag is v{version}, and publish fires on ^v\d+\.\d+\.\d+$. The release history matches: v2.47.0, v2.45.0 and v2.44.0 carry the assets.

The upshot is that the README section this PR rewrites is now accurate, and merging the rewrite would re-document the behaviour we just removed. My suggestion is to close this as fixed rather than merged. It did its job by surfacing the misconfiguration.

One small gap remains if you want to land something here: the README does not name the publish job, which is publish-release.

Two bits of residue worth knowing about:

1. cargo-fslabscli-2.46.0 and cargo-fslabscli-2.47.0 still exist as bare tags with no releases attached, left over from the old tag format. That has already caused one real bug in a Dockerfile that fetched a release asset from one of them.
2. The infra config carries an INTERIM note that the release pipeline is mid-migration to the gitops job-config chart, to revisit September 2026. Job names may move again when that lands.