[refactor-opportunist] Centralize gh-aw release binary installation

## 🏗️ Refactor Proposal

**Summary:** Move gh-aw release-binary installation into one reusable script so the normal and compatibility compiler setup paths cannot drift apart.

## Problem

`Makefile` previously contained one 21-line `install-gh-aw-from-release` macro that embedded OS detection, architecture mapping, release URL construction, downloading, and executable setup. Both `setup-gh-aw` and `setup-gh-aw-compat` independently supplied output paths and version-file handling around that macro. Any change to release asset naming, download behavior, or version stamping required synchronized edits across both setup paths.

The two compiler setup branches are at `Makefile:123-145` and `Makefile:147-166`; both now delegate to the same helper.

## Proposed Approach

Keep the Makefile responsible for selecting release versus Go installation and for choosing the output paths. Move release-specific mechanics into `scripts/install-gh-aw-release.sh`, with explicit arguments for version, output binary, and version file. Retain the existing non-release Go fallback unchanged. Migrate the remaining setup/install helpers to this script incrementally if they acquire similar release-download behavior.

## Proof of Concept

I partially implemented this refactor for both gh-aw compiler setup paths.

**Files changed:**
- `scripts/install-gh-aw-release.sh:1-53`
- `Makefile:123-166`

**Before → After:**

```make
# Before: release download logic lived in a Make macro and each target wrapped it
$(call install-gh-aw-from-release,$(GH_AW_BUILD_VERSION),.bin/gh-aw)

# After: both targets use one explicit installer interface
./scripts/install-gh-aw-release.sh "$(GH_AW_BUILD_VERSION)" ".bin/gh-aw" ".bin/.gh-aw-version"
./scripts/install-gh-aw-release.sh "$(GH_AW_COMPAT_VERSION)" ".bin/gh-aw-compat" ".bin/.gh-aw-compat-version"
```

The helper centralizes validation, OS/architecture mapping, URL construction, download fallback (`curl`/`wget`), executable permissions, and version-file stamping. The old macro has no remaining references; the new helper has exactly two call sites.

## Incremental Rollout Plan

1. **Completed proof of concept:** route both `setup-gh-aw` and `setup-gh-aw-compat` release branches through the shared script.
2. **Follow-up:** route any future release-installed repository tools through similarly focused installers rather than adding download logic to the Makefile.
3. **Cleanup:** keep Makefile targets limited to orchestration and preserve tool-specific fallback logic only where the installation mechanism genuinely differs.

## Risks and Mitigations

- **Risk:** shell behavior could diverge from the former Make macro. **Mitigation:** the helper preserves the same supported OSes, architecture aliases, release URL format, download fallback, chmod, and version stamping; it also adds explicit argument/version validation.
- **Risk:** future callers may pass inconsistent output paths. **Mitigation:** the interface makes the three required artifacts explicit and keeps the target-specific paths visible at each call site.

## Evidence

- `Makefile:123-166` contains the two compiler setup flows and their shared helper call sites.
- `scripts/install-gh-aw-release.sh:18-52` contains the centralized release-installation behavior.
- Recent churn includes compiler version/setup changes in the Makefile and generated workflows, increasing the value of keeping setup logic in one place.

## Verification

- `bash -n scripts/install-gh-aw-release.sh` — passed.
- `make -n setup-gh-aw setup-gh-aw-compat` — passed.
- `make lint` — passed; workflow and composite-action validation completed and catalog validation reported 37 reachable workflows.
- `UV_CACHE_DIR=/tmp/gh-aw/agent/uv-cache uv run --extra test pytest tests/test_check_nav_catalog.py -q` — 9 passed.
- `git diff --check` — passed.

> [!WARNING]
>
> Firewall blocked 1 domain
>
> The following domain was blocked by the firewall during workflow execution:
>
> - `awmgmcpg`
>> To allow these domains, add them to the `network.allowed` list in your workflow frontmatter:
>
> ```yaml
> network:
> allowed:
> - defaults
> - "awmgmcpg"
> ```
>
> See [Network Configuration](https://github.github.com/gh-aw/reference/network/) for more information.
>
>

---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Trigger Refactor Opportunist](https://github.com/elastic/ai-github-actions/actions/runs/30278012997)

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

Start with Makefile:123-166 and scripts/install-gh-aw-release.sh:1-53, comparing both setup targets with the former release-installation behavior described in the issue. Run bash -n scripts/install-gh-aw-release.sh and make -n setup-gh-aw setup-gh-aw-compat, then verify both paths use the shared arguments, preserve fallback behavior, and pass the listed validation checks.

Written by the indexing model from the issue text.