fix(release): harden immutable desktop promotion

[Git-on-my-level]

Summary

Follow-up to #10163 that closes the final immutable-release review gaps discovered after the original PR merged.

• Dispatches privileged qualification at the exact candidate tag and checks out the event SHA.
• Triggers automatic Beta promotion only from a completed, successful, same-repository qualification workflow_run; the qualifier no longer dispatches promotion while still in progress.
• Verifies Stable static JSON/HTML publication against the retained manifest.
• Requires all four Stable/Beta installer identities in the release doctor.
• Requires typed confirmation before both Stable promote and retained-manifest repoint operations.
• Strengthens production deployment mutation guards for pre-auth rejection ordering and multiline persistent image overrides.
• Corrects stale Beta backend/bundle/diagnostics documentation.

Product invariants affected

• INV-AUTH-1
• INV-INT-1
• INV-MEM-1

Failure-Class: FC-split-mutation-authority

Verification

• Candidate-tag/completed-qualification mutation tests
• Stable confirmation/static publication tests
• Four-asset release doctor tests
• Production boundary/direct-writer mutation tests
• Desktop release and update backend suites
• actionlint on touched workflows
• make preflight
• git diff --check

Safety

No workflow was dispatched. No cloud resource, release asset, Beta/Stable pointer, appcast, production bundle, credential, or deployment was mutated.

[Git-on-my-level]

Superseded by the owner-selected single-artifact architecture in #10192 and the planned consolidated release-readiness PR. Do not merge the obsolete dual-identity/four-asset contract.

[github-actions]

Hey @Git-on-my-level 👋

Thank you so much for taking the time to contribute to Omi! We truly appreciate you putting in the effort to submit this pull request.

After careful review, we've decided not to merge this particular PR. Please don't take this personally — we genuinely try to merge as many contributions as possible, but sometimes we have to make tough calls based on:

• Project standards — Ensuring consistency across the codebase
• User needs — Making sure changes align with what our users need
• Code best practices — Maintaining code quality and maintainability
• Project direction — Keeping aligned with our product principles and locked invariants

Before your next PR, please skim:

• PRODUCT.md — product north star
• Product invariants — locked rules (shared chat, memory tiers, agent control plane, integrations, brand)

If this was declined for direction or taste, maintainers should cite an invariant ID or open a proposed one — ask if that citation is missing.

Your contribution is still valuable to us, and we'd love to see you contribute again in the future! If you'd like feedback on how to improve this PR or want to discuss alternative approaches, please don't hesitate to reach out.

Thank you for being part of the Omi community!