[refactor-opportunist] Unify gh-aw compiler install path in Makefile

## 🏗️ Refactor Proposal

**Summary:** Consolidate `gh-aw` and `gh-aw-compat` installation logic onto one parameterized `Makefile` path so version/pin upgrades require fewer synchronized edits.

## Problem
The repository currently has tightly coupled compiler setup surfaces that change together:

- `Makefile:122-165` had two separate install flows (`setup-gh-aw` and `setup-gh-aw-compat`) with duplicated cache/version handling and repeated install behavior.
- `.github/workflows/agentics-maintenance.yml` repeats pinned setup refs/versions in multiple jobs (for example `:92`, `:130`, `:159`, `:174-177`, `:216`, `:260`, `:275-277`, `:304`, `:319-321`).
- 60-day churn signal shows frequent co-change pressure:
- `Makefile` touched in **23** commits
- `agentics-maintenance.yml` touched in **19** commits
- both touched together in **15** commits (`P(both|agentics-maintenance)=0.789`, `P(both|Makefile)=0.652`)
- Representative co-change commit: `d29e958` modifies both `Makefile` and `.github/workflows/agentics-maintenance.yml`.

This coupling makes upgrades and maintenance noisier than necessary and increases risk of drift.

## Proposed Approach
Create one canonical installer flow in `Makefile` and make compat installation call that flow with explicit overrides:

- Keep one setup implementation (`setup-gh-aw`) as the canonical path.
- Parameterize binary name, version file, target version, label, and source/module repo.
- Route `setup-gh-aw-compat` through `setup-gh-aw` using those override variables.

This preserves behavior while reducing structural duplication and making future version-related changes easier to apply consistently.

## Proof of Concept
I partially implemented this refactor on one representative slice to verify viability.

**Files changed:**
- `Makefile`

**Before → After:**

1. Added install parameters near the version block:

```make
GH_AW_BIN ?= gh-aw
GH_AW_VERSION_FILE ?= .gh-aw-version
GH_AW_TARGET_VERSION ?= $(GH_AW_BUILD_VERSION)
GH_AW_LABEL ?= compiler
GH_AW_INSTALL_SOURCE ?= $(GH_AW_SOURCE_REPO)
GH_AW_INSTALL_MODULE ?= $(GH_AW_MODULE_REPO)
```

2. Converted `setup-gh-aw` to use those parameters (cache checks, install source/module logic, and version-file writes now flow through one implementation).

3. Replaced the duplicate `setup-gh-aw-compat` body with a delegated call:

```make
setup-gh-aw-compat:
@$(MAKE) --no-print-directory setup-gh-aw \
GH_AW_BIN=gh-aw-compat \
GH_AW_VERSION_FILE=.gh-aw-compat-version \
GH_AW_TARGET_VERSION=$(GH_AW_COMPAT_VERSION) \
GH_AW_LABEL='compat compiler' \
GH_AW_INSTALL_SOURCE=$(GH_AW_MODULE_REPO) \
GH_AW_INSTALL_MODULE=$(GH_AW_MODULE_REPO)
```

**Verification:**
- `make lint` ✅
- `make test` ✅ (`53 passed`)

## Incremental Rollout Plan
This refactor can be completed incrementally:

1. **Completed now:** Consolidate Makefile installer duplication (canonical + compat delegation).
2. Introduce one repository-level gh-aw version manifest (consumed by both Makefile variables and maintenance workflow generation inputs).
3. Add a drift check in CI to fail when maintenance workflow setup pins diverge from the canonical version contract.

## Risks and Mitigations
- **Risk:** Parameterization could accidentally alter compat install behavior for non-tag versions.
**Mitigation:** Keep current defaults and add a small Make target smoke check for both binaries in CI.
- **Risk:** Version-source contract remains split until workflow generation is wired to the same manifest.
**Mitigation:** Land this Makefile consolidation first (already proven), then migrate workflow pin wiring in a follow-up PR.

## Evidence
- `Makefile:11-16` (new install parameters)
- `Makefile:128-153` (canonicalized installer path)
- `Makefile:155-162` (compat delegation)
- `.github/workflows/agentics-maintenance.yml:92,130,159,174-177,216,260,275-277,304,319-321` (repeated setup pin usage)
- `git log --since="60 days ago"` co-change counts above
- commit `d29e958` touching both `Makefile` and `.github/workflows/agentics-maintenance.yml`

> [!NOTE]
>
> 🔒 Integrity filter blocked 16 items
>
> The following items were blocked because they don't meet the GitHub integrity level.
>
> - [#600](https://github.com/elastic/ai-github-actions/pull/600) `search_pull_requests`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#687](https://github.com/elastic/ai-github-actions/pull/687) `search_pull_requests`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#378](https://github.com/elastic/ai-github-actions/pull/378) `search_pull_requests`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#851](https://github.com/elastic/ai-github-actions/pull/851) `search_pull_requests`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#589](https://github.com/elastic/ai-github-actions/pull/589) `search_pull_requests`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#608](https://github.com/elastic/ai-github-actions/pull/608) `search_pull_requests`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#359](https://github.com/elastic/ai-github-actions/issues/359) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#1067](https://github.com/elastic/ai-github-actions/issues/1067) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#676](https://github.com/elastic/ai-github-actions/issues/676) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#704](https://github.com/elastic/ai-github-actions/issues/704) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - elastic/ai-github-actions#1067 `list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - elastic/ai-github-actions#1025 `list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - elastic/ai-github-actions#875 `list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#245](https://github.com/elastic/ai-github-actions/issues/245) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#225](https://github.com/elastic/ai-github-actions/issues/225) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#224](https://github.com/elastic/ai-github-actions/issues/224) `search_issues`: 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: Trigger Refactor Opportunist](https://github.com/elastic/ai-github-actions/actions/runs/25325800487)

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