ci: Split release preparation and publishing

[karthikbekalp]

What was the problem/requirement? (What/Why)

The release workflow waited for asynchronous Conda production promotion and required a manual approval before completing public publication. This required maintainer coordination and left a long gap between preparation and release completion.

What was the solution? (How)

Split publication into two workflows:

• Release: Prepare creates or validates the tag, runs unit and xa11y integration tests, builds and stages installers, and publishes the Python package to CodeArtifact.
• Preparation is restricted to the canonical repository and mainline.
• Release: Publish runs every six hours or on demand and checks the public Conda manifest for the exact cinema4d-openjd version on linux-64 and win-64.
• The public manifest is treated as confirmation that Conda promotion completed across all production waves.
• Automatic publication considers only the newest valid release tag. Newer tags intentionally supersede older unpublished tags.
• The selected tag is validated before releasing installers, publishing to PyPI, and creating the GitHub Release.
• The GitHub Release is created after installer publication and before PyPI. It acts as the completion marker so scheduled runs cannot repeatedly release installers; a PyPI failure is recovered by rerunning the failed job from the original workflow run.
• Force-publishing requires an explicit tag and approval through the release-gate environment.

What is the impact of this change?

Release completion becomes unattended once the package reaches the public Conda manifest. The previous manual readiness gate is removed because production-wave completion is represented by the manifest and required manual coverage has been replaced by xa11y integration tests.

Normal release preparation and artifact publication remain serialized through the shared release concurrency group.

How was this change tested?

• Existing Code Quality, CodeQL, and Security Scan checks passed.
• Ran a release-readiness smoke workflow in a personal fork. It verified ready, pending, four-day timeout, and approved manifest-override paths.
• Manually dispatched Release: Publish in readiness-only mode to verify a ready release, pending release, approved override, and expected timeout failure. The timeout harness captured and asserted the action's failure, so the test run itself completed successfully; the production workflow does not suppress that failure. Publication jobs were skipped during these checks.
• End-to-end publication was not run because it would modify production release artifacts.
• Submitter integration tests were not run because this change only modifies release automation.

Was this change documented?

The release automation design guide was updated to document the latest-release-only publication policy.

Is this a breaking change?

No. This changes internal release automation and does not modify the submitter or adaptor interfaces.