[Feature]: Publish one project Release per unified version #133

Affected modules

Repository only

Problem and use case

The owner requires one GitHub project Release with one consolidated changelog per unified version. #23/#24 aligned versions and root notes but retained a GitHub Release per module. v0.2.0 has 27 published Releases; the current #129/#132 candidate would repeat that behavior. Go needs prefixed tags for independent modules, not component Release objects.

Proposed behavior

• New preparations explicitly freeze a single-project publication mode: one root Release and its existing grouped notes, with all maintained module tags on the reviewed commit.
• Create tags and verify public proxy/checksum consumers in dependency order; finalize the project Release only after every module consumer succeeds. Failed publication keeps a recoverable root draft and an open tracking issue.
• Derive subsequent component history from a published root Release and a matching component tag at the same commit; drafts, unrelated/conflicting tags and incomplete cohorts cannot become release boundaries.
• Link module rows to actual tags/source, not nonexistent component Releases.
• Preserve historical v0.1.0/v0.2.0 tags, Releases, notes and frozen legacy plan recovery. Refresh the pending RC proposal after the workflow fix rather than changing its frozen source.

Alternatives considered

A single Go module would change existing dependency boundaries. Hiding or relabeling 26 component Releases still creates unnecessary publication objects. Keep independent modules and tags, and publish only the root summary.

Acceptance criteria

• Unified publication creates one root draft/final Release; zero component Release writes, one version, exact shared tag SHA, and all module consumers checked before finalization/issue closure.
• Failed consumer/finalization runs resume safely without rewriting tags or notes. Conflicts and API errors stop before unsafe writes; preflight creates no tags/Releases.
• Subsequent patch/candidate/stable preparation uses correct root-backed component boundaries without duplicated changes. Missing/mismatched component tags and draft-only roots are rejected/excluded.
• Stable root is Latest; candidates are prereleases and do not become Latest. Legacy plan behavior stays immutable.
• Offline regression, pinned GoReleaser, workflow lint, required CI and English documentation pass; record verified scope in docs/CHECKLIST.md.
• No actual candidate/stable publication, historical Release deletion or AWS calls in this implementation.

Compatibility and dependencies

Repository publication policy only; no Go API, module path or runtime dependency changes. New plans mark the policy explicitly so historical frozen notes/recovery remain verifiable. #129 remains open until publication and public acceptance; #132 is replaced after the source fix.

Before submitting

• Searched existing issues and the roadmap.
• Removed credentials and private data.