release: gate next-to-main promotions and define rollback readiness

[ss-o]

Problem

next is currently 32 commits ahead of main, with work accumulated since 2023. main is not merely a release branch: the public installer and z-shell/zd default to cloning main, so a promotion changes the code new users consume immediately.

The repository now has useful checks on next (Zsh, ZD Integration, Trunk, and CodeQL), and the current head passes them. However, the live rulesets do not require those checks on next; the main ruleset requires only Guard main branch source. The pull-request template says to promote after integration checks pass but does not define a promotion-specific readiness record, migration notes, or rollback decision.

The current review also found three user-visible compatibility regressions that required focused fixes in #368, #370, and #372. That is evidence that green syntax and broad integration checks alone are not a sufficient promotion policy.

Proposed scope

Define and enforce a small promotion gate specifically for same-repository next to main pull requests. Keep ordinary feature pull requests lightweight and preserve the class-3, Git-consumed publication model.

Acceptance criteria

Required validation

• Expose stable required-check contexts for Zsh syntax/compile validation, ZD ZUnit integration, Trunk, and CodeQL, or document an equivalent aggregate gate that cannot report success while a constituent check is failing or skipped.
• Configure next and main rulesets so the appropriate validation is required, not merely observed.
• Run ZD integration against an immutable Zi commit after z-shell/zd#93 is complete.
• Add a clean-install/startup smoke test for the exact promotion candidate, including a fresh Zi data directory and no pre-existing checkout.

Promotion record

• Add a promotion-specific template or generated checklist recording the next and main SHAs, the complete compare URL, required-check results, and unresolved known issues.
• Require consolidated user-facing notes for behavioral changes, with explicit no migration required rationale when applicable.
• Require links to documentation or consumer follow-ups identified by the public-contract impact report tracked in #376.
• Require completion of the focused compatibility suite tracked in z-shell/zd#94 before this large promotion.

Rollback readiness

• Define observable rollback criteria, an owner, and the supported hotfix/revert path before merge.
• Record the previous main SHA so recovery does not depend on creating an extra release tag.
• Verify that a reverted promotion restores a clean install and startup; do not use a force-push rollback on protected main.

Tag boundary

• Reference #346 for publication policy rather than coupling every main update to an automatic tag.
• A promotion may complete without a tag; a user-facing semantic tag remains a separately approved publication act with release notes and green validation.

Out of scope

• An arbitrary coverage percentage.
• Automatically editing consumer repositories.
• Automatically publishing a tag or GitHub release on every main update.
• A permanent freeze of ordinary work on next.