release: gate publication on green integration and verified images

[shenjiecode]

Summary

The current tag/release path can publish a GitHub Release before the corresponding integration suite and runtime images have succeeded. We should make release publication fail closed on the exact candidate commit and artifacts.

This is now a concrete blocker for the next prerelease containing the hard-cut Team/Worker contract from #1072.

Current evidence

At main commit 37c31b77d4e88ca87a1270c61a1e6f659e8023e1:

• AgentTeams Controller Tests passed.
• Image build jobs in the main-push Integration Tests run passed.
• Nine integration matrix shards passed.
• integration-tests (controller-cr-2, SHARD_D_TESTS, copaw, copaw) failed in test-21-team-project-dag with the bounded failure: Leader did not coordinate the task in Team Room within timeout.
• Cleanup and artifact collection completed, but the overall Integration Tests workflow is red: https://github.com/agentscope-ai/AgentTeams/actions/runs/30146563035

This may be behavioral nondeterminism or a regression, but a red required integration boundary must not be converted into release evidence without a classified rerun/fix.

Current workflow risk

.github/workflows/release.yml supports manual dispatch and immediately:

1. creates/pushes the requested tag;
2. builds a release body from the checkout;
3. creates the GitHub Release.

The tag separately triggers Build Images and Integration Tests. Those workflows run in parallel; Release does not wait for either result or verify published image manifests.

Additional fail-open edges:

• git tag ... || echo "Tag already exists, skipping" and git push ... || echo "Tag already pushed, skipping" allow the workflow to proceed after a version collision or failed push;
• the release body advertises image tags without proving that those tags exist for the exact release commit and required architectures;
• workflow dispatch can build release notes from the current checkout even when the requested tag already points elsewhere.

The v1.2.0-beta.1 release page also currently describes spec.workerMembers, while its immutable tag 78d0ceda336befa6e62bf89fc1a6b08b965e128d still contains the legacy inline Team contract. That mismatch is tracked in #902 and demonstrates why source, notes, images, and installer must be bound to one immutable candidate.

Proposed acceptance criteria

Before the next public prerelease:

• Select one candidate commit and persist its full SHA.
• Reject an existing version tag unless it resolves to that exact SHA; never continue after tag/push failure.
• Build all release images from the candidate and publish by immutable digest or staging tag.
• Run required Controller and Integration suites against the candidate artifacts, including Team DAG and the hard-cut Worker/Team lifecycle.
• Require every release-gating job to be green; classify/rerun flaky tests explicitly rather than ignoring red checks.
• Verify every advertised image manifest exists for the required architectures and corresponds to the candidate.
• Verify installer, embedded controller, CRDs, CLI, runtime images, changelog, and release notes expose the same contract.
• Only then create/promote the immutable version tag and GitHub prerelease.
• Keep stable latest tags unchanged for prereleases.
• Archive the changelog from the tagged content and ensure release notes describe only that tag.

Scope

This issue is about release ordering and evidence, not changing the Team/Worker contract itself. The contract release gate and downstream Tiangong acceptance evidence are recorded in #902.