[bug-hunter] get_release_commit.sh returns oldest matching release commit when version repeats

## Impact
`dev/scripts/get_release_commit.sh` is documented as the helper to find the release commit for backport workflows, but when the same version appears multiple times in history it can return an older commit instead of the latest release commit. This can point release/backport automation at stale history.

## Reproduction Steps
1. Run this new minimal repro script:

```bash
#!/usr/bin/env bash
set -euo pipefail

WORK=/tmp/gh-aw/agent/get-release-repro
rm -rf "$WORK"
mkdir -p "$WORK"
cd "$WORK"

git init -q
git config user.email test@example.com
git config user.name test

mkdir -p packages/foo
printf 'name: foo\nversion: 0.1.0\n' > packages/foo/manifest.yml
git add .
git commit -q -m init

printf 'name: foo\nversion: 1.0.0\n' > packages/foo/manifest.yml
git commit -qam first_release
FIRST=$(git rev-parse --short HEAD)

printf 'name: foo\nversion: 0.2.0\n' > packages/foo/manifest.yml
git commit -qam revert

printf 'name: foo\nversion: 1.0.0\n' > packages/foo/manifest.yml
git commit -qam second_release
SECOND=$(git rev-parse --short HEAD)

RESULT=$(/home/runner/work/integrations/integrations/dev/scripts/get_release_commit.sh -p foo -v 1.0.0)

echo "first=$FIRST"
echo "second=$SECOND"
echo "result=$RESULT"
```

2. Execute it:

```bash
bash /tmp/gh-aw/agent/repro_get_release_commit.sh
```

(Equivalent direct run produced:)

```text
first=84288d6
second=a9365bc
result=84288d6
```

## Expected vs Actual
**Expected:** return the most recent commit that introduced `version: 1.0.0` (`second`, `a9365bc` in repro).

**Actual:** returns the older matching commit (`first`, `84288d6`).

## Failing Test
```bash
#!/usr/bin/env bash
set -euo pipefail

# Fails today: script returns oldest matching commit, not latest.

WORK=/tmp/gh-aw/agent/get-release-repro-test
rm -rf "$WORK"
mkdir -p "$WORK"
cd "$WORK"

git init -q
git config user.email test@example.com
git config user.name test

mkdir -p packages/foo
printf 'name: foo\nversion: 0.1.0\n' > packages/foo/manifest.yml
git add . && git commit -q -m init

printf 'name: foo\nversion: 1.0.0\n' > packages/foo/manifest.yml
git commit -qam release_v1_first

printf 'name: foo\nversion: 0.2.0\n' > packages/foo/manifest.yml
git commit -qam move_off_v1

printf 'name: foo\nversion: 1.0.0\n' > packages/foo/manifest.yml
git commit -qam release_v1_second
EXPECTED=$(git rev-parse --short HEAD)

ACTUAL=$(/home/runner/work/integrations/integrations/dev/scripts/get_release_commit.sh -p foo -v 1.0.0)

if [[ "$ACTUAL" != "$EXPECTED" ]]; then
echo "FAIL: expected latest commit $EXPECTED, got $ACTUAL"
exit 1
fi

echo "PASS"
```

## Evidence
- `dev/scripts/get_release_commit.sh:67` sorts commit IDs with `sort -u`, which loses git-history recency order.
- `dev/scripts/get_release_commit.sh:72-77` picks the first commit that adds the version, so after sorting it can select an older commit.
- Script usage in backport docs: `docs/extend/developer-workflow-support-old-package.md:34-44`.

> [!NOTE]
>
> 🔒 Integrity filter blocked 1 item
>
> The following item were blocked because they don't meet the GitHub integrity level.
>
> - [#19391](https://github.com/elastic/integrations/pull/19391) `search_pull_requests`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
>
> To allow these resources, lower `min-integrity` in your GitHub frontmatter:
>
> ```yaml
> tools:
> github:
> min-integrity: approved # merged | approved | unapproved | none
> ```
>
>

---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Bug Hunter](https://github.com/elastic/integrations/actions/runs/27204687767)

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
> - [x] expires on Jun 16, 2026, 12:12 PM UTC