Release blocker: protect main and v* release tags before v1.3.0-rc.1

[fraware]

This is a release-integrity blocker for v1.3.0-rc.1.

Observed on 2026-08-26:

• main reports protected=false.
• repository rulesets endpoint returns [].
• automated/generated pushes can advance main, so a mutable branch name cannot define release identity.
• final technical-closure PR Final release closure: trust roots, obligation identity, claim discipline #23 was followed by documentation/ref-integrity closure PR Final RC closure: status accuracy and immutable ref protection #26 because the prior candidate contained stale living release status.

Current candidate state:

• PR Final RC closure: status accuracy and immutable ref protection #26 merged as GitHub-verified commit 40fefb4de8b59978fa338fc09d3a185d5708bc1f.
• That SHA is provisional only until the complete exact-head pre-tag development matrix (CI, Repro baseline, Native Backends Tier 1, Native Backends Tier 1b) succeeds on it.
• The superseded candidate 99f478a3af5a5505d05319db8a816a0053089fe8 must not be tagged for rc.1.
• If any further source/document change is made, the candidate SHA changes again and the full exact-head gate plus consumer repinning must be repeated.

Required before public publication:

1. Protect main against force-push and deletion.
2. Require pull-request based changes to main except for narrowly justified automation; do not weaken exact-SHA release authorization to accommodate automation.
3. Add an active release-tag ruleset for v* (or a stricter equivalent covering this RC and future releases) that prevents deletion and update after creation.
4. Preserve the release architecture: the signed annotated v1.3.0-rc.1 tag must point directly to the exact final candidate SHA after the pre-tag matrix passes, and GitHub must report its signature verified.
5. Do not create a GitHub Release manually; .github/workflows/publish.yml owns the draft -> PyPI -> exact read-back -> public transition.

Acceptance evidence:

• live branch/ruleset state shows main protected against force-push/deletion;
• live ruleset state shows release tags protected against update/deletion;
• exact final candidate has all four required pre-tag development workflows successful;
• signed tag verification and direct target are independently checked before any tag-bound evidence dispatch.

This issue should be closed only after those live repository settings and exact-head gates are verified, not from documentation alone.