docs: clarify release communication checkpoints

[tisonkun]

Summary

• define the review, sender, and completion evidence for public release communications
• apply the same checkpoint model to [VOTE], [CANCEL][VOTE], [RESULT][VOTE], and [ANNOUNCE]
• require mailing-list thread URLs in the release tracking issue so a prepared draft cannot be mistaken for a completed step

Why

The release guide is shared by release managers and the tools that support them. Public communications need an explicit responsibility and completion boundary, but describing that boundary in terms of agents or automation makes the runbook less natural for human readers.

The revised wording is operational instead: populate each message from verified release state, review its recipients and release-specific values, send it from the release manager's Apache email account, and record the resulting thread URL. These are useful instructions and observable completion criteria regardless of how the draft and supporting evidence were prepared.

This is a rolling documentation improvement and does not change or invalidate the already tagged, published, staged, and verified 0.5.0 RC1 candidate.

Commits

1. docs: mark release communications as human handoffs
2. docs: express release communication as checkpoints

Validation

• cargo x lint
• git diff --check