feat(ci): promote a nightly fill to a draft tests release

[danceratopz]

🗒️ Description

This makes the "cutting tests@ releases directly from the nightly artifact" follow-up from ethereum#3100 concrete: a new promote_nightly.yaml workflow turns a nightly fill into a draft tests@<version> release without refilling. Since the nightly fills the mainnet tests feature through the exact release pipeline, its fixtures_tests artifact is already release-shaped; promotion downloads it and mirrors the release job's gh release create invocation, targeting the exact commit the nightly built, so publishing the draft creates the tag on that commit. The job runs in minutes on a hosted runner; nothing is filled.

gh workflow run promote_nightly.yaml -f version=vX.Y.Z
# or promote a specific nightly run instead of the newest one:
gh workflow run promote_nightly.yaml -f version=vX.Y.Z -f run_id=<run-id>

By default the newest scheduled run with a live fixtures_tests artifact is promoted: skip-runs upload no artifacts and expired fills cannot be downloaded, so both are passed over; run_id promotes a specific run instead. Validation lives in a standalone, unit-tested promote_nightly.py, deliberately self-contained rather than sharing helpers with check_new_commits.py so the two workflows stay decoupled. It fails fast when:

• the version is not vX.Y.Z or does not exceed the newest existing tests@ tag;
• no nightly run with a live fixtures_tests artifact exists (past the five-day retention: dispatch a full release instead);
• the promoted commit is not an ancestor of the branch head.

Commits that landed after the promoted nightly are listed in the run's step summary as not included, so the releaser can choose between promoting and dispatching a fresh full release.

Commits, in order:

• feat(ci): The workflow, the resolution/validation script with its unit tests (10 new cases on the existing fake-gh harness), and a new docs section in docs/dev/releasing_tests.md.
• docs(ci): Unwrap docs/dev/releasing_tests.md and correct the tag-timing wording: gh release create --draft only stores the tag name and target commit as draft metadata, and the git tag is created when the draft is published. This applies to the existing manual release flow too, so a mispicked version can be fixed by editing the draft, with no stray tag to delete.

Notes, flagging for visibility:

• Drafts do not reserve their tag name, so two parallel promotions of the same version would silently coexist as separate drafts; a promote-nightly concurrency group serializes promotions to prevent this.
• Like the nightly cron path, promotion cannot be exercised in PR CI; it is worth one dispatch validation run on a fork before relying on it.

🔗 Related Issues or PRs

Targets the head branch of ethereum#3100, implementing the "cutting tests@ releases directly from the nightly artifact" follow-up listed there.

✅ Checklist

• All: Ran fast static checks to avoid unnecessary CI fails, see also Code Standards and Verifying Changes:

  just static

• All: PR title have the form <type>(<area>):, where <type> and <area> come from an approrpriate C-<type>, respectively A-<area>, label. The title should match the a target squash commit message.
• All: Considered updating the online docs in the ./docs/ directory.

Cute Animal Picture

[spencer-tb]

Lets go!!