ci: prepare releases for Apache Trusted Releases

[tisonkun]

Summary

Configure Apache Trusted Releases (ATR) through .asf.yaml and use ATR for new release candidates, from staging through publication.

• Sync project metadata, source archive classification, email vote recipients, the 72-hour minimum, and the existing version-based download layout using the official project schema.
• Update the release skill for uploads, artifact checks, pinned revisions, both Incubator vote rounds, publication, and retries. Preserve continuity for candidates already staged in SVN.
• Reuse the release manager's signing key and SVN-managed KEYS. Keep one-time automated signing and OIDC upload onboarding in the optional infrastructure reference. The existing crates.io Trusted Publishing workflow remains unchanged.

Revalidated locally against main at 87017f9: cargo x lint, the current official ASF project schema, skill validation, internal links, Markdown table alignment, and git diff --check pass. git range-diff confirms that the rebase preserves the original patch. Live ATR staging, voting, and publication remain to be exercised during the first release trial.

Follow-up order, tracked in #303:

1. Before the next release: verify the merged configuration in ATR, the committee's podling status, and the existing signing-key import. Confirm both vote recipients and the final incubator/asyncband/${VERSION}/ destination.
2. Run one release through ATR: prepare the version/changelog and existing release checks, upload the locally signed source, verify the downloaded bytes, complete both vote rounds, and publish the approved artifacts. Record the Git commit/tag, ATR revision, digests, vote results, and publication state so interruptions resume the same candidate.
3. Automate candidate preparation: add a manually triggered workflow with reproducible source bundles, then complete ASF automated-key onboarding and enable compose-only OIDC upload. Separate preparation, signing, and upload jobs; validate retries and preservation of candidate identity before scheduling it.
4. Add scheduling and lifecycle integration: define the weekly cutoff and version-selection policy, skip unchanged source and active candidates, and connect recorded IPMC approval to the approved commit's final tag and protected crates.io publication. Test overlapping runs, rejected candidates, and partially successful publication before enabling the schedule.