fix: let a first release open at v0.1.0 (ENG-9233)

[ENG-9233](https://stacklet.atlassian.net/browse/ENG-9233)

What
----

- Narrows the first-release guard from "the bump has to be major" to "the bump
  cannot be patch", so a repository with no tags can open at `v0.1.0` as well
  as at `v1.0.0`.
- Updates the `bump` input description and the README to match, both in this
  repository's own caller and in the block the README offers for copying.

Why
----

The guard exists to stop a first release landing `v0.0.1`, which immutable
releases make permanent. Refusing `patch` covers that on its own. Refusing
everything except `major` also blocks `minor`, which lands `v0.1.0` and is how
a project opens when it is not ready to call its interface settled. The
workflow was deciding a question that belongs to the repository calling it.

This surfaced while versioning the five module repositories for this ticket.
Two of them have no tags, so the guard forced them to `v1.0.0`, and the other
three were then argued up to match for consistency. Only the first step of
that was the tooling's to make.

Testing
----

- [x] `just lint` passes.
- [x] `uvx zizmor@1.23.1 -v --gh-token=... .github/workflows/` reports no
      findings, with the five online audits scheduled rather than skipped.
- [x] Walked the guard against each bump at the `0.0.0` baseline: `patch` is
      refused, `minor` and `major` pass. Confirmed against semver that those
      land `v0.0.1`, `v0.1.0` and `v1.0.0` respectively, so the refused case is
      the only one worth refusing.
- [x] Confirmed the bump check runs before this step, so comparing against the
      literal `patch` cannot be defeated by a mixed-case input the way a raw
      workflow expression otherwise would.
- [ ] After merge, dispatch Release here with a `minor` bump and confirm
      `v1.1.0` publishes against `v1.0.0` as previous.
- [ ] The first dispatch on `terraform-aws-stacklet-cur-setup` exercises a
      `minor` bump from an empty tag history against the real guard.

Docs
----

The README's description of the refusals now says the first release cannot be a
patch, and names what minor and major open at.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: johnsca

.github/workflows/cut-release.yml

@@ -113,16 +113,18 @@ jobs:
 
       # Only fires on the first release, where the baseline is 0.0.0. A patch
       # from there lands v0.0.1 permanently, so this is enforced rather than
-      # left to the input description. Reads `previous_version` rather than
-      # `previous_tag`, which carries the action's tag prefix and would make
-      # this a second copy of a default owned elsewhere.
-      - name: Require the first release to be major
-        if: ${{ steps.version.outputs.previous_version == '0.0.0' && inputs.bump != 'major' }}
-        env:
-          BUMP: ${{ inputs.bump }}
+      # left to the input description. Minor and major both land somewhere
+      # usable, so whether a repository opens at v0.1.0 or v1.0.0 is left to
+      # the caller rather than decided here. Reads `previous_version` rather
+      # than `previous_tag`, which carries the action's tag prefix and would
+      # make this a second copy of a default owned elsewhere. Compares against
+      # `patch` directly, which is safe because the bump check above has
+      # already rejected anything outside the three lowercase values.
+      - name: Refuse to open a repository at v0.0.1
+        if: ${{ steps.version.outputs.previous_version == '0.0.0' && inputs.bump == 'patch' }}
         run: |
-          echo "This repository has no releases yet, so the first one has to be a" >&2
-          echo "major bump to land v1.0.0. This run asked for ${BUMP}." >&2
+          echo "This repository has no release tags, so a patch bump would land" >&2
+          echo "v0.0.1. Ask for minor to open at v0.1.0, or major for v1.0.0." >&2
           exit 1
 
   publish:

.github/workflows/release.yml

@@ -4,7 +4,7 @@ on:
   workflow_dispatch:
     inputs:
       bump:
-        description: Which part of the version to raise. The first release has to be major, because the count starts from 0.0.0.
+        description: Which part of the version to raise. The first release has to be minor or major, because the count starts from 0.0.0.
         required: true
         type: choice
         default: patch

README.md

@@ -63,7 +63,7 @@ on:
   workflow_dispatch:
     inputs:
       bump:
-        description: Which part of the version to raise. The first release has to be major, because the count starts from 0.0.0.
+        description: Which part of the version to raise. The first release has to be minor or major, because the count starts from 0.0.0.
         required: true
         type: choice
         default: patch
@@ -95,8 +95,9 @@ jobs:
 
 The workflow refuses to run against anything but the calling repository's default
 branch, refuses any re-run of a run it has already started, and refuses to publish over
-a tag it did not create. A retry means dispatching again. The first release has to be a major bump, because the version
-walk starts from 0.0.0 and a patch from there spends `v0.0.1` permanently.
+a tag it did not create. A retry means dispatching again. The first release cannot be a
+patch bump, because the version walk starts from 0.0.0 and a patch from there spends
+`v0.0.1` permanently. Minor opens a repository at `v0.1.0` and major at `v1.0.0`.
 
 `STEP_SECURITY_API_KEY` is optional. Without it the Harden Runner step is skipped and
 the rest runs unchanged.