ci: add public release mirror workflow

[haasonsaas]

Summary

• add the public-owned release mirror fallback workflow to evalops/maestro
• unblock prepared public mirror guardrails generated from internal main
• preserve the internal/public mirror boundary by keeping this workflow in the public repo

Validation

• bunx biome check .github/workflows/public-release-mirror.yml test/scripts/ci-guardrails.test.ts
• node ./scripts/run-vitest.js --run test/scripts/ci-guardrails.test.ts -t "registry-smokes real public release mirror fallback publishes" (public main test set currently skips this internal-only guard until next mirror sync)
• temp prepared-mirror simulation from evalops/maestro-internal@633fa7e: node scripts/run-prepared-public-mirror-guardrails.mjs --target /tmp/maestro-public-guardrail.Rympao/public-mirror
• git diff --check

Staged rollout

Staging is unnecessary: this PR only adds the public repository's release mirror fallback workflow and does not change runtime product behavior.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 24ab298fcc

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Select runner by repository, not pull_request-only logic

The runs-on expression always resolves to vars.INTERNAL_CONFIRMATION_RUNNER || 'evalops-internal' for this workflow’s actual triggers (push tags and workflow_dispatch), because both branches of the ternary guarded by github.event_name == 'pull_request' are unreachable here. In the public repo this skips the normal public fallback (vars.PUBLIC_PR_VALIDATION_RUNNER || 'ubuntu-latest') used by other release workflows, so release-mirror runs can be stranded on an internal-only label instead of executing.

Useful? React with 👍 / 👎.