[EaZyCheaZ]

Task: cowork-p1-version-numbering-001. Issues: none (only Dependabot pull requests were open when the task was written).

Version numbers now follow the release flow (docs/development.md#versions):

1. Patch = dev builds: every pull request into dev (dependency updates too) takes the next patch on dev's line.
2. Minor = QA cycles: a promotion to QA takes dev's version as it is; the next pull request into dev starts the next minor at .0. This pull request is that one: QA has 0.4.17, so it's 0.5.0 (the new rule landed first).
3. Staging adds a beta pre-release: staging's image is published as x.y.z-beta.N; N counts the line's (x.y) publishes to staging.
4. Production removes it: "ship it" releases staging's exact code as x.y.z (written down in the docs, not scripted).
5. Majors: 1.0.0 is the first public release; after that a major only with a For admins line led by Before you upgrade:. Until 1.0, never.

A fix into qa or staging takes the next free patch on that branch's own line. dev, qa and staging never share a version.

What enforces it

• .github/version_rules.py: the rules, next, the beta counter and the merge-back merge, with a 34-case self-test (CI's Changelog job runs it). release.sh check-changelog calls it in place of the old "higher than all three branches" loop.
• ./release.sh next-version [dev|qa|staging] prints the number the next pull request takes.
• promote-qa and promote-staging take --dry-run and report the versions they produce; promote-staging records Published to staging as: x.y.z-beta.N in its pull request.
• merge-back merges CHANGELOG.md and QA-CHECKLIST.md itself when they conflict: every version of both, in version order, highest first (each line's versions stay together); the build version is the changelog's top.
• Dependency updates take dev's next version from the same rules.

Where the beta suffix lives

• The record: the Image workflow tags each staging publish's commit vx.y.z-beta.N (it now has contents: write for that). The next number is one more than the line's highest tag; a commit that already has one (a re-run) keeps it. promote-staging reads the same tags with git ls-remote --tags, so it needs no package access (the image is still private).
• The image: tags staging and x.y.z-beta.N, with the beta version as its version label and baked in as REQUESTARR_RELEASE_VERSION.
• The app on the beta server: its version card for the version it runs (Requestarr 0.4.17-beta.1 · …, still found as 0.4.17's card), the private full card, System → Status (0.4.17-beta.1 (0.4.17.12345)), and the logo's hover text. Every other version and every other server shows the plain number.

Also: the live QA check now runs as the newest version that has checklist items, so a version with nothing to test by hand (like 0.4.17) doesn't break it.

Tests

• Version rules self-test 34/34; Dependabot script 18/18; changelog and checklist checkers pass.
• release.sh check-changelog against the real branches with throwaway commits: dev 0.5.0 passes, 0.4.18 and 0.5.1 fail; QA fix 0.4.18 passes, 0.5.0 and 0.4.19 fail; staging fix (as staging will be after the next promotion) 0.4.18 passes, 0.5.0 and 0.4.19 fail.
• Requestarr core tests: 1071 passed, 0 failed, 3 skipped (platform-only). Inherited API and host tests: 33 passed, 1 skipped.