chore(release): enforce v* tag-ruleset drift check (flip TAG_RULESET_ENFORCED)

[joeharris76]

Pull Request

Description

Flip TAG_RULESET_ENFORCED False→True now that the v* tag-creation
ruleset is live. Admin applied v-tag-restricted (id 18774756) on
2026-07-10: active, conditions.ref_name.include=[refs/tags/v*], a
creation rule, and bypass_actors=[User:57046 (always)] — the
release-finalize identity only, confirmed not a broad Write/Admin role (so
make release-finalize's git push origin v$(VERSION) still succeeds).

The single constant in _project/scripts/ruleset_review_enforcement.py drives
both consumers: the standalone predicate main() and
scripts/ruleset_drift_check.py:tag_creation_findings(), which imports it as
the enforce_tag_rule default. Flipping it turns a missing/incomplete v*
tag ruleset from a non-blocking WARNING into a blocking finding in
release-canary.yml's ruleset-drift job — so a future regression (ruleset
deleted, made inactive, ref narrowed, creation rule dropped, or bypass
emptied) fails CI instead of merely warning.

This does not change enforcement of the tag ruleset itself (GitHub already
enforces it); it arms the drift detector to treat a regression as blocking.

Type of Change

• Refactor / chore

Testing

• pytest tests/unit/release/ tests/unit/test_ruleset_drift.py tests/unit/test_release_infrastructure.py — 104 passed.
• Ran the runbook's live predicate against the actual rulesets with the
  flag flipped: Tag-creation ruleset - OK, exit 0 — confirms the canary
  stays green and enforcement only arms on a future regression.

Public Contract Check

• I updated docs/reference/public-contracts.md, or this PR does not change
  public, beta-public, deprecated, generated, experimental, or repo-only
  contract surfaces. (No contract surface changed — internal release-tooling flag.)
• I checked result schema fields, MCP tool parameters, platform support
  status, wrapper facades, adapter subclassing hooks, and generated docs for
  contract-map impact. (None affected.)
• Any platform/benchmark count claim in docs is generated/checked from
  registry metadata, or explicitly marked editorial/non-authoritative. (N/A.)

Documentation

• I updated the relevant user-facing docs. (Filled the runbook's tag
  live-state note in docs/operations/repo-admin-settings.md — the
  precondition the flag comment requires before flipping.)
• I added regression notes for behavior changes. (Runbook note + commit body.)
• I confirmed API contract wording remains accurate.

Code Quality

• I ran formatting and lint/type checks. (pre-commit ran on commit.)
• I reviewed impacted modules for backwards compatibility and migration impact.

Notes for reviewer

• Coupling with chore: rename release branch main->release in-repo (w1-w4) #1027 (the main→release rename): none. chore: rename release branch main->release in-repo (w1-w4) #1027 edits
  scripts/ruleset_drift_check.py and the branch-rename prose in
  repo-admin-settings.md; this PR edits _project/scripts/ruleset_review_enforcement.py,
  the test file, and the tag live-state note block (lines are disjoint from
  chore: rename release branch main->release in-repo (w1-w4) #1027's runbook hunks), so no overlapping conflict.
• The sibling DEVELOP_REVIEW_RULE_ENFORCED flip is intentionally not
  included here — it lives in scripts/ruleset_drift_check.py, which chore: rename release branch main->release in-repo (w1-w4) #1027
  also edits, so it should ride chore: rename release branch main->release in-repo (w1-w4) #1027 or land after it to avoid a conflict.

🤖 Generated with Claude Code