Desktop releases: clarify qualification, beta, stable-candidate, and stable terminology

[Git-on-my-level]

Problem

The desktop pipeline currently uses bless / blessed for the exact-tag T2 qualification that normally promotes a non-live build candidate into beta. This is easy to read as “approved for production,” even though stable promotion is a later, explicit production decision.

The desired lifecycle vocabulary is:

main → build candidate → qualified beta → stable candidate → stable

• Build candidate: signed/notarized, non-live artifact built from main.
• Qualified beta: candidate with exact-tag T2 evidence; eligible for and normally promoted to beta.
• Stable candidate: a qualified beta deliberately nominated for stable promotion, after soak/telemetry/release-note review; it is not stable yet.
• Stable: selected by the explicit production workflow only.

Why this is more than a docs typo

The old wording appears in the qualification script and artifacts, beta workflow input/job copy, release metadata/error messages, Codemagic output, agent instructions, developer docs, and the stable-promotion guard. A partial rename would preserve the confusing product model.

Current implementation evidence:

• desktop/macos/scripts/bless-release.sh rebuilds an exact candidate, runs T2, uploads evidence, and dispatches beta promotion.
• .github/workflows/desktop_promote_beta.yml calls its input a “Blessed … candidate”.
• .github/scripts/prepare-desktop-beta-promotion.py requires blessed* metadata.
• .github/workflows/desktop_promote_prod.yml performs the distinct, typed-confirmation stable promotion.

Proposed implementation

1. Make qualification the canonical beta gate

• Rename the user-facing script and its help/output from bless-release.sh to a clear qualified-beta term, e.g. qualify-desktop-beta.sh.
• Rename temporary bundle/worktree/log/evidence labels from bless to qualification.
• Rename workflow prose to Qualify Desktop Beta / Promote Qualified Desktop Beta.
• Update Codemagic messages, AGENTS.md, desktop agent guidance, developer docs, and runbooks to use the lifecycle above.

2. Preserve existing evidence compatibility safely

• Treat existing blessed, blessedSha, blessedAt, blessedTier, and blessedEvidence metadata as legacy aliases when reading prior releases.
• Introduce canonical qualification terminology/keys only with a dual-read migration and tests; do not make already-qualified beta releases unpromotable.
• Keep the stable-promotion guard requiring exact-tag qualification evidence. Only its user-facing terminology should change.

3. Make the pre-stable decision explicit

• Add a stable_candidate nomination state, with release tag/SHA, timestamp, nominator, rationale, and qualification evidence reference.
• Provide a non-customer-facing nomination action/workflow that validates: qualified-beta status, beta pointer equality, and required soak/telemetry/release-note inputs.
• Make stable promotion accept only a nominated stable candidate by default; retain a typed, audited break-glass path for urgent exceptions.
• Stable nomination must never move the stable pointer, mutate the beta channel, or deploy production.

4. Documentation and operator ergonomics

• Document the exact promotion decision point and expected evidence.
• Update release/check summaries to say qualified beta or stable candidate, never merely blessed.
• Ensure manual stable promotion still requires confirm=promote-stable and remains the only workflow that changes stable visibility.

Acceptance criteria

• A new operator can correctly identify whether a tag is a build candidate, qualified beta, stable candidate, or stable from workflow/release metadata and docs.
• A qualified beta does not become stable merely by qualification or nomination.
• Existing releases carrying only legacy blessed* metadata remain valid inputs to stable promotion.
• Stable promotion requires explicit stable-candidate nomination plus typed confirmation, except for an audited break-glass override.
• Tests cover legacy metadata parsing, canonical metadata parsing, candidate → qualified beta, qualified beta → stable candidate, and stable-candidate → stable guardrails.
• Search-based regression checks ensure desktop release/operator docs no longer use bless to mean beta qualification.

Relationship

Follow-up/clarification of #9350. This changes release vocabulary and makes the beta-to-stable handoff explicit; it does not relax any channel-safety or manual-production invariant.