feat(action): add event-driven CI-ready signaling to replace publish polling

[BYK]

Summary

• Add ci_ready input to the prepare action and reusable workflow (default true, opt-out with 'false')
• When enabled, the publish issue is created with a ci-pending label and a check-ci-status dispatch is sent to the publish repo to trigger the CI status poller immediately
• New publish_issue_number output for downstream use

Context

craft publish currently polls GitHub's commit status API every 30 seconds for up to 60 minutes (waitForTheBuildToSucceed) inside a Docker container. This idle polling is billed as GitHub Actions minutes and steals from our available capacity — a publish job that waits 45 minutes for CI burns 45 minutes of runner time doing nothing.

This PR adds the ci-pending label at issue creation time and dispatches a signal to the publish repo's centralized CI status poller (getsentry/publish#7674). The publish job doesn't start at all until CI passes — zero wasted runner minutes. Target repos need zero changes.

Label	Meaning
ci-pending	CI signal expected but not yet received
ci-ready	CI passed, ready to publish
accepted	Approved for publishing (unchanged)

ci_ready defaults to true — all repos using the reusable workflow get the new behavior automatically. Repos that need the legacy polling can opt out with ci_ready: 'false'.

Cross-Repo Dependency

Works with getsentry/publish#7674 (centralized CI status poller).

[sentry]

Bug: The ci_ready input defaults to 'true' instead of the intended 'false', causing release workflows to stall for any repository that has not explicitly opted into the new CI signaling mechanism.
_{Severity: CRITICAL}

Suggested Fix

Change the default value for the ci_ready input to 'false' in action.yml and the reusable workflow in .github/workflows/release.yml to align with the intended opt-in behavior. This ensures existing workflows are not affected unless they explicitly set ci_ready: 'true'.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: action.yml#L53-L54

Potential issue: The `ci_ready` input in `action.yml` defaults to `'true'`, but the
feature is designed to be opt-in with a default of `'false'`. This causes the action to
add a `ci-pending` label to publish issues for all repositories by default. Repositories
that have not adopted the corresponding `signal-ready` action will have their release
process blocked indefinitely, as they will be waiting for a signal that is never sent.
This affects both external repositories using the action and the project's own
dogfooding release workflow, which does not pass the `ci_ready` input and thus uses the
incorrect default.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[BYK]

Closing — the publish repo's self-contained poller (getsentry/publish#7674) handles everything: adds ci-pending on issue creation, checks CI status via self-dispatch, flips to ci-ready when green. No craft changes needed.