gh-release mode: add PR-body extraction fallback to match git-ref mode fidelity

[Mpdreamz]

Context

The Release Notes Onboarding RFC (docs-eng-team#698) specifies that the git-ref bundling mode (--start-git-ref/--end-git-ref) should prefer a checked-in S3 changelog entry and fall back to changelog add-style PR-body extraction (reading the release_notes: block from the PR description).

The existing gh-release mode (changelog gh-release) currently produces entries with only title + PR link — it does not extract the release_notes: block from PR bodies. This creates a content fidelity gap: products using the On-release GitHub Release path (APM agents, Beats agents, etc.) get lower-quality release notes than serverless products using the git-ref path.

Required change

Update GitHubReleaseChangelogService to apply the same extraction precedence as the git-ref mode:

1. If a checked-in S3 changelog entry exists for the PR (already synced via changelog-upload), use it.
2. Otherwise, attempt PR-body extraction (Extract.ReleaseNotes / the same path used by changelog add).
3. Fall back to title/link-only only if neither source is available.

This normalises release-note quality across all On-release trigger shapes.

Related

• docs-eng-team RFC: https://github.com/elastic/docs-eng-team/pull/698
• GitHubReleaseChangelogService.cs
• git-ref mode spec: docs/rfcs/release-notes-serverless-deployment.md (docs-eng-team)

[lcawl]

Re: "If a checked-in S3 changelog entry exists for the PR (already synced via changelog-upload), use it", I think this would be nice to have in the changelog add command in general. I think it currently overwrites the existing file (if you're using PR-based or issue-based filenames) or adds a new variation of the file (if you're using timestamp-based filenames). It would be nice to make that configurable or at least return a warning when you've overwritten an existing file.