ci(release): add guarded web publish dispatch

[seakee]

Summary

Add a first-class Web/Actions release publication path so an approved main release candidate can be dry-run and then published without temporary helper workflows, while preserving the existing tag-push path and release immutability rules.

Scope

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

Changes

• Extend Build and Release manual dispatch with explicit dry-run and publish modes.
• Require publish to provide the exact approved main SHA, a successful prior dry-run ID for the same version/repository/SHA, and explicit publish confirmation.
• Create and re-read the lightweight release tag inside the approved publish run instead of relying on a second tag-triggered workflow event.
• Keep the existing direct tag-push entry path supported.
• Make publish reruns fail closed: attempt 1 rejects any pre-existing tag; later attempts may reuse only the exact tag pointing directly to the approved release SHA.
• Explicitly bind OCI revision, version, and source labels to the release candidate rather than GitHub event context.
• Verify pushed image provenance, required linux/amd64 + linux/arm64 manifests, and enabled-registry digest agreement before publishing the draft GitHub Release.
• Add unit and workflow-contract coverage for dry-run identity, exact-SHA authorization, tag creation/reuse, OCI provenance, image verification ordering, and Telegram rerun behavior.
• Update docs/release.md with the Web publish flow, contributor acknowledgement gate, and recovery semantics.

User Impact

No application runtime behavior changes. Maintainers can publish a validated release directly from GitHub Actions / Web tooling without creating temporary publisher workflows. The release process remains two-stage: successful dry-run first, then explicit publish against the exact same main SHA.

Compatibility / Runtime Notes

• Existing externally created lightweight v* tags remain supported by the normal tag-push release path.
• workflow_dispatch must run from main.
• Publish mode requires the exact expected_sha, successful dry_run_id, and confirm_publish=true.
• A publish rerun can recover only when the existing tag still points directly to the approved release SHA.
• No database, API, runtime, or upgrade migration is involved.

Data / Security Notes

• The publish gate uses the job-scoped GITHUB_TOKEN and validates repository, workflow path/name, run status, run event, version-specific run title, branch, exact SHA, and prior dry-run completion before creating a ref.
• The first publish attempt fails if the target tag already exists.
• No tag mutation, retargeting, overwrite, or deletion path is added.
• Docker provenance is explicitly checked before the draft GitHub Release is made public.
• Telegram remains non-idempotent and is still automatically delivered only on workflow attempt 1.

Risk / Rollback

Risk level: Medium. This changes the release control plane, not product runtime behavior. The main risks are incorrectly authorizing a publish dispatch or changing release sequencing; both are covered by fail-closed guards and repository-level tests.

Rollback by reverting this PR. The existing tag-push release path remains independently supported.

Verification

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

Commands / evidence:

• Added isolated authorization tests for successful/failed dry-run identity, exact SHA, first-attempt tag absence, rerun exact-tag reuse, and mismatched tag rejection.
• Added workflow-contract tests for dispatch inputs, tag creation path, OCI labels, image verification ordering, and Telegram attempt gating.
• Full repository PR CI is expected to exercise the changed release workflow and repo-level tests.

Screenshots / Recordings

N/A — release automation / CI behavior 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: docs/release.md is the canonical operator documentation for this release-process capability; no end-user product release note is required.

Related

Refs #775