fix(release): support large version package commits

[bokelley]

What changed

• restore changesets/action@v1 for Version Packages branch updates
• retain the Changesets v3 git-tag publish command
• document why the v1 git transport is required for large generated releases

Why

The AdCP 3.2.0-beta.0 Version Packages update contains tens of thousands of generated schema and compliance files. changesets/action@v2 attempts to write that release commit through one GraphQL mutation, which GitHub rejects because the payload exceeds 45 MB. The previous v1 action successfully generated the same beta-scale artifact set by pushing the commit through git.

Validation

• npm run test:release-workflow
• npm run test:immutable-release-artifacts

[aao-secretariat]

(non-blocking) The fix's durability rests on @v1 never carrying the GraphQL createCommitOnBranch path that v2 uses. @v1 is a floating major tag: a future v1.x that backports the API-commit behavior silently reintroduces the exact 45 MB failure this PR exists to avoid — on the release path, discovered only at the next beta cut. Base already floated @v2, so this is consistent, not a regression. Worth pinning this release-critical, size-sensitive action to an exact tag or commit SHA as a follow-up.

[aao-secretariat]

Ladon verdict: Escalate to human review

Escalate — gated path requires human/CODEOWNERS review.

This PR modifies .github/workflows/release.yml, a gated path (matches .github/workflows/**). gated_paths is true and review_decision is REVIEW_REQUIRED (not APPROVED), so decision-table row 2 fires: the hard approval gate is not satisfied and the outcome cannot be approve or plain comment.

There are no blocking (critical/high) findings. The change downgrades the changesets/action from v2 to v1 on the Version Packages step so the large beta-scale release commit is pushed via git rather than a single GraphQL createCommitOnBranch mutation that exceeds GitHub's payload cap. The v2→v1 input translation is correct, and the empty changeset is appropriate for a workflow-only change on a protocol-scoped path.

Escalation reasons

• .github/workflows/release.yml (modified) is a gated path; human/CODEOWNERS review is required because review_decision is REVIEW_REQUIRED, not APPROVED.

Medium findings

• None.

Non-blocking note (low)

• .github/workflows/release.yml:120 — fix durability depends on the floating @v1 tag not backporting the GraphQL commit path.

Why human review

• .github/workflows/release.yml (modified) is a gated path (.github/workflows/**); review_decision is REVIEW_REQUIRED, not APPROVED — human/CODEOWNERS review required before merge.
• This PR touches a path under a hard, non-overridable approval gate (.github/workflows/release.yml (modified) matches .github/workflows/**) and the current GitHub review decision is 'REVIEW_REQUIRED', not APPROVED. This is a hard gate enforced in code — Ladon cannot auto-approve until a human/CODEOWNERS approval is recorded, regardless of how clean the diff is.

[aao-secretariat]

Ladon verdict: Escalate to human review

Escalate — gated path requires human/CODEOWNERS approval.

This PR modifies .github/workflows/release.yml, which matches the deterministic gated path glob .github/workflows/** (gated_paths: true). The required review status is REVIEW_REQUIRED, not APPROVED, so the hard approval gate (decision rule row 2) is not satisfied and the PR cannot be auto-approved.

The change itself is clean and well-scoped: it downgrades the changesets/action from v2 to v1 in the release workflow so the beta-scale "Version Packages" commit (tens of thousands of generated schema/compliance files) is pushed via git rather than a single GraphQL createCommitOnBranch mutation that would exceed GitHub's 45 MB payload cap. The v1 input remapping (version/publish/commit/title/createGithubReleases + GITHUB_TOKEN env) is complete and internally consistent, the App-token downstream-trigger behavior and cosign tarball signing are preserved, and the empty changeset is the correct required artifact for this CI-only change. The reviewer surfaced no blocking or Medium findings.

No Critical/High/Medium findings exist, but the workflow-file gate stands until a human or CODEOWNERS marks the PR APPROVED.

Escalation reasons

• Modifies .github/workflows/release.yml (matches gated path .github/workflows/**) and review_decision is REVIEW_REQUIRED — human/CODEOWNERS approval required before merge.

Why human review

• Modifies .github/workflows/release.yml (matches gated path .github/workflows/**) while review_decision is REVIEW_REQUIRED — human/CODEOWNERS approval required.
• This PR touches a path under a hard, non-overridable approval gate (.github/workflows/release.yml (modified) matches .github/workflows/**) and the current GitHub review decision is 'REVIEW_REQUIRED', not APPROVED. This is a hard gate enforced in code — Ladon cannot auto-approve until a human/CODEOWNERS approval is recorded, regardless of how clean the diff is.