docs: record the release-* ruleset, which now exists

[johanzander]

Follow-up to #635. The Protect stable hotfix branches ruleset now exists:

id=20972632  refs/heads/release-*  non_fast_forward  enforcement=active  bypass_actors=[]

#635 shipped with a ⚠️ in CLAUDE.md saying release-X.Y was unguarded at both layers, plus a matching comment in quality-check.sh. That was accurate when written and is now false. A doc asserting a gap that has been closed misleads exactly as much as one asserting a guard that does not exist — and both failure modes have already happened once each in this area today.

Changes

• Adds the release-* row to the ruleset table (four → five)
• Replaces the ⚠️ with the reason for the one asymmetry in that table

The asymmetry, since it will look like an oversight later

release-* blocks non_fast_forward and deliberately not deletion, unlike every other branch ruleset here. The branch is pushed and tagged by the release skill (steps 2–6), so rewriting it must fail — but deleting it once the release is out is ordinary cleanup and must not. What makes dropping the deletion guard safe is the tag ruleset one row up: the published tag pins the released commit, so a spent release-* branch costs nothing to lose. Before tagging it is recoverable only from a local reflog, so delete it after, not during.

One wording trap

--delete release-X.Y is still permitted, so the summary above the table cannot say the rulesets "refuse every line above" — it refuses every rewrite. I wrote the wrong version first and corrected it before pushing; flagging it because the same sentence is the natural thing to write next time the table changes.

Verification

scripts/quality-check.sh — 0 errors, 0 warnings. Docs and comments only; no behaviour change.

[bess-agent]

@claude-bot review

[bess-manager-claude-bot]

Verdict: APPROVE

Fact-check

Verified against live GitHub state (gh ruleset view 20972632 --repo johanzander/bess-manager), not just the diff text: the Protect stable hotfix branches ruleset exists exactly as claimed — refs/heads/release-*, rule non_fast_forward only, enforcement=active, empty bypass list. The new table row and the replaced ⚠️ block are accurate; nothing here asserts a guard or a gap that isn't real.

Checklist

• Matches linked context: this is a follow-up to #635 recording a ruleset created after that PR merged, not an issue fix — no root-cause claim to check, and the description is honest about that.
• Minimal/no scope creep: only CLAUDE.md and scripts/quality-check.sh touched, both comment/doc text. No behavior change, confirmed by running the PR's version of quality-check.sh locally — the permission-surface section (the only part this diff can affect) reports ✅ Permission surface intact (76 command shapes checked, 20 require deny, 26 must stay unattended). The 4 errors in my run are pre-existing local environment gaps (missing .venv/frontend deps in this checkout), unrelated to the diff.
• Rule violations: none. No code touched, so the Python/API/error-handling checklist items don't apply. Comment style matches the file's existing WHY-focused convention.
• Wording-trap check called out in the PR body: correct — the new prose says "refuse every rewrite" rather than "refuse every line," and that matches reality (--delete release-X.Y is still permitted).

One non-blocking gap

scripts/quality-check.sh:190 (top comment block) and scripts/quality-check.sh:343 (MUST_NOT_BE_GUARDED preamble) both now document the new mapping:

#   git push origin +release-9.9        -> non_fast_forward on release-*
...
#   +release-X.Y (rewrite)                       -> refused by a ruleset

but the MUST_NOT_BE_GUARDED array itself (scripts/quality-check.sh:353-355) only carries the pre-existing "git push origin --delete release-9.9" entry — there's no new pinned string like "git push origin +release-9.9" alongside it, unlike the exactly analogous sibling "git push origin +beta-release-9.9" on the line above, which pins that ruleset-guarded rewrite case.

This file is unusually explicit about why that pinning matters ("asserts this by COMMAND STRING, not by rule name... When a new bypass spelling turns up, add the string to the right list first"). This PR introduces exactly that situation — a new ruleset-guarded push spelling — documents it in prose, but doesn't add the parallel pinned entry the other three ruleset-guarded spellings (main --force, +beta-release-*, tag force) all have. It doesn't break anything (script is green either way; verified locally), so it's not a blocker — just worth a fast follow-up so the new spelling gets the same command-string coverage as its siblings.