feat: publish a GitHub release in release step 4 and make it idempotent

[morningman]

What problem does this PR solve?

Issue Number: None

Related PR: #507

Problem Summary:

After a release vote passes, 04-release-complete.sh only uploaded the source
artifacts to release SVN and wrote the announcement draft. The GitHub tag was
still left as a bare tag and had to be converted into a release by hand, and a
run that stopped halfway (SVN commit already done, mail draft not written)
could not simply be repeated: the script aborted with "SVN version directory
already exists".

This PR does three things:

1. Turn the released tag into a GitHub release. Once the release files are
   in release SVN, the script writes github-release-notes.md under
   WORK_DIR, prints it for review, and publishes it with
   gh release create --verify-tag after a confirmation. --verify-tag means
   the existing tag is published and no tag is ever created. The notes link:

   • the release-note issue (RELEASE_NOTES_URL),
   • the operator image apache/doris:operator-<version> (DOCKER_IMAGE),
     with its docker pull command and Docker Hub page (DOCKER_IMAGE_URL),
   • the formal source artifacts, KEYS, and the verification guide.

2. Make the whole run idempotent, so an interrupted release can just be
   re-run:

   • release files already present in release SVN are detected by name, and
     packaging, signing, and the SVN commit are skipped (no GPG passphrase
     prompt either);
   • a release directory holding only some of the three files is reported as
     incomplete and stops the run for manual repair;
   • an existing GitHub release whose notes already match is left untouched;
     differing notes are replaced only after an explicit confirmation;
   • new --github-only flag publishes or refreshes only the GitHub release
     (mutually exclusive with --mail-only).

3. Add the mail subject to the drafts. vote-email.txt and
   announce-email.txt carried the body only, so the title had to be retyped.
   Both now start with a Subject: line followed by a blank line, and step 4
   prints the subject like step 3 already did.

New release.env entries: GITHUB_REPO, DOCKER_IMAGE, DOCKER_IMAGE_URL
(all validated; DOCKER_IMAGE must end with the current VERSION, which
catches a stale image tag after a version bump). gh is a new prerequisite of
step 4 and must be authenticated for GITHUB_REPO.

The version-specific defaults are moved on to the released 26.0.1, and the
hardcoded version assertions in tests/test-config.sh now derive from
VERSION, so they no longer need editing on every release.

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

  tools/release-tools/tests/run.sh passes. The suite uses temporary Git
  repositories and fake gpg/svn/gh commands; it touches no real keyring,
  remote repository, SVN repository, GitHub release, or mail system. New cases
  cover: the GitHub release creation (including --verify-tag and the notes
  content), a repeated run of a finished release (no re-sign, no SVN commit, no
  GitHub write), an incomplete release directory, --github-only, the
  --mail-only/--github-only conflict, and the Subject: line of both mail
  drafts.

• Behavior changed:

  • No.
  • Yes.

  04-release-complete.sh now also publishes a GitHub release and requires
  gh; repeating a finished run reports the completed steps and continues
  instead of failing; both mail drafts gained a leading Subject: line.

• Does this need documentation?

  • No.
  • Yes.

  tools/release-tools/README.md is updated in this PR.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

🤖 Generated with Claude Code