chore: refine the release skill after the 0.7.3 release

[orthur2]

Summary

Refine the release skill with what the 0.7.3 release run showed, tracked in #327.

• Say how a new release manager's public key reaches KEYS, since ATR imports the committee's keys from the distribution area rather than accepting an upload.
• Describe both release environment approvals, for composition and for the final tag, as actions for a reviewer listed in .asf.yaml, which the release manager performs only when listed there.
• State the plain-text conventions for vote messages, since mailing lists do not render Markdown.
• Tell the release manager to cast their own vote on ATR or in the thread, since a release manager has no implicit +1 under the ASF voting process.
• Note that ATR renders the second round's message from the stored template, so candidate details written by hand in the first round do not carry over.
• Note that ATR neither resolves an email vote nor sends a reminder when it ends.
• Add updating the website Downloads page before the announcement, in the runbook and the tracking issue checklist, which the 0.7.2 and 0.7.3 releases both needed.
• Add the rerun recovery path for a failure caused outside the repository: the composed bundle is reused, a reviewer approves again, and GitHub accepts reruns for 30 days.
• State ATR's naming rule for the automated signing key in the composition troubleshooting, including the error text it produces. The 0.7.3 RC1 upload failed this check while the key was present in KEYS, so the existing pointer did not lead to the cause. See Automated source release upload to ATR fails: project signing key UID does not match ATR naming #329.

Validation: cargo x lint.

[tisonkun]

I think we may try to see if ATR supports defining the email template as code instead of defining it on the platform. Then we can keep the email template in our repository. Then we don't need Point 3 at all, but that can be a follow-up to investigate.

[orthur2]

Agreed. And I took a look at the ATR code. Its "Export .asf.yaml" already writes start_vote_template, start_vote_subject, announce_release_template and a few other template fields under project.policy, so it seems we could keep the templates in our .asf.yaml, since we already have atr_sync on. I haven't checked yet whether the asfyaml side accepts those keys. I'll look into how to optimize this part later.

[tisonkun]

This can be a follow-up PR that we review separately BTW.

[tisonkun]

Rest generally looks good.

[orthur2]

Thanks for the review, I'll update this draft PR later.