docs(release): define release readiness gate

[seakee]

Summary

Define a mandatory release-readiness gate that runs before the existing release integration and publication flow. The gate standardizes pre-release product/runtime/data/deployment review and makes large UI changes require an explicit, SHA-bound manual walkthrough.

Scope

• Frontend panel
• Manager Server
• CPA panel mode
• Full Docker mode
• Native packages / release
• Docs / Wiki
• CI / build / tooling

Changes

• Add docs/release-readiness.md as the mandatory Gate 0 before the existing release workflow.
• Bind release-readiness evidence to the exact remote dev candidate SHA.
• Define five review dimensions: product boundary, runtime/upstream contracts, data/upgrade safety, deployment/packaging, and UI/UX.
• Define UI-0, UI-1, and UI-2 risk classes.
• Require release-specific targeted QA for UI-1 and explicit operator-confirmed detailed manual QA for UI-2.
• Define a dynamic UI QA matrix covering data states, display variants, localization, themes/layout, interaction, and shared-component regressions.
• Define blocking/non-blocking/out-of-scope finding handling without expanding release scope.
• Define SHA invalidation and incremental revalidation when dev advances after readiness approval.
• Define the standard readiness handoff to the existing integrate/validate and tag/publish gates.

User Impact

No application runtime behavior changes. Maintainers get a reproducible pre-release QA gate so a request to publish vX.Y.Z starts by proving the current product candidate is ready, rather than immediately creating release artifacts.

Compatibility / Runtime Notes

Documentation-only. The existing release branch, promotion, dry-run, Web publish, tag-push compatibility, and recovery mechanics are unchanged.

Data / Security Notes

No data, migration, credential, or permission changes. The new process explicitly requires data/upgrade and runtime-contract risk review when those areas are affected.

Risk / Rollback

Risk level: Low. This is a maintainer-process document and does not change executable release automation.

Rollback by reverting this PR if the readiness policy proves too burdensome or needs restructuring.

Verification

• Tests
• Docs/link check
• Type check
• Lint
• Build
• Manual UI check
• Not applicable, docs-only

Commands / evidence:

• Branch is based exactly on current dev merge c9d9db3506274fbe26a50fe6dac02258fd8d01af.
• Diff contains only the new release-readiness process document.
• Repository PR CI will validate docs build and template requirements.

Screenshots / Recordings

N/A — documentation/process only.

Docs

• README / README_CN updated for user-visible capabilities
• Matching docs manual and navigation updated
• Demo fixtures, screenshots, and deep links reviewed
• Release notes needed
• Not needed — explanation included below

Docs decision: the new file is the canonical Gate 0 maintainer process document and is intentionally separate from the existing mechanical release/publish specification.

Related

Refs #775
Refs #776