[hdamker]

What type of PR is this?

• cleanup

What this PR does / why we need it:

Replaces the six command jobs with two: snapshot (/create-snapshot, which needs the validation toolchain) and act (everything else, dispatched by release_automation/scripts/act.py). The workflow now has four jobs (plan, snapshot, act, finalize), three job conditions, and 583 lines (was 1,324).

• plan has one JSON plan output (decision plus the release references and base context the later jobs read), action, finalize and result_comment_id. The compatibility outputs are gone. command_policy.py decides the action: the slash command, create-draft or publish-on-merge (by publish_mode) on a Release PR merge, reopen-issue on a close in snapshot-active/draft-ready.
• snapshot and act each write one JSON outcome (the old output names); finalize reads it from toJSON(needs).
• With publish_mode: on_merge, finalize posts release_published (or publish_failed) as a new comment on the Release Issue, then opens the sync PR and closes the issue as after /publish-release. All policy values are still draft.

Behaviour differences:

• A Release Issue closed in planned/published, and any reopen, no longer starts a job that does nothing; finalize syncs the issue directly.
• A Release PR merge with a broken release-plan.yaml no longer tries to create a draft with an empty tag.
• act fails when its action fails (discard, delete, publish used to end green with success=false); finalize still posts the failure comment.
• make_latest for an on_merge public release is set in a separate call, as for drafts.

Which issue(s) this PR fixes:

Part of #476

Special notes for reviewers:

Targets release-automation-refactor. The canary covers plan → snapshot → finalize and act for /discard-snapshot and reopen-issue; draft creation, /delete-draft and /publish-release are covered by the manual end-to-end test after merge. technical-architecture.md §3.3 is rewritten in a later PR.

Changelog input

 release-note

Additional documentation

docs