Temporarily downgrade gh-aw compiler to v0.87.1 to bypass threat-detection engine failures

## What

Temporarily downgrade the gh-aw compiler pin (`GH_AW_VERSION` / `GH_AW_BUILD_VERSION` / `GH_AW_COMPAT_VERSION` in `Makefile`) from `v0.87.10` to `v0.87.1`, and recompile all workflow lock files.

## Why

Several agentic workflows generated from this repo (e.g. `gh-aw-pr-review.lock.yml`, consumed by `elastic/docs-builder`'s `pr-review.yml` via `@v0`) have started failing their `detection` job with:

> Threat Detection Engine Failure — The analysis engine could not complete. This is a tooling failure, not a security finding.

Root cause: upstream `github/gh-aw` `v0.87.2` enabled **external threat detection by default** ([gh-aw#54111](https://github.com/github/gh-aw/pull/54111)), switching the `detection` job from an inline copilot-prompt-based check to an external `threat-detect` (v0.5.1) binary run inside the `awf` sandbox. That external binary has an open upstream bug — [github/gh-aw-threat-detection#1014](https://github.com/github/gh-aw-threat-detection/issues/1014) — where it reports `invalid_report_exhausted` even though the Copilot engine successfully invoked the `threat_detection_result` tool with a valid verdict (a temp-file path/race mismatch, not a real invalid report). Because `GH_AW_DETECTION_CONTINUE_ON_ERROR=true` is set, the job still reports overall success while silently producing no verdict, and the confusing/failing `detection` job output is what's visible to workflow users.

`v0.87.1` predates the `v0.87.2` default-on switch, so it still uses the older inline detection path and is unaffected by this bug.

## Investigation already done

- Confirmed `v0.87.1` is **not** in gh-aw's compat blocklist (`compat.json`; blocked range is `v0.82.8–v0.85.3`), so it won't hard-fail activation like the earlier attempt to pin `v0.83.4` did.
- Confirmed the separate `safe-inputs` → `mcp-scripts` rename (which caused the PR-review "silent noop" regression, fixed in #1974) is unaffected either way — that rename landed upstream in March 2026, long before `v0.83.4`, and the `ready-to-code-review` tool compiles correctly at both `v0.87.1` and `v0.87.10`.
- Compiled all 57 workflows locally with both `v0.87.1` and `v0.87.10` compilers and diffed the output. `v0.87.1` compiles cleanly (0 errors, same warnings as `v0.87.10`).

## Known tradeoffs of downgrading (accepted as temporary)

- No `timeout-minutes: 90` guard on the `agent` job (falls back to GitHub Actions' 360-minute default).
- Missing `GH_AW_PR_HEAD_BASE_*` / `GH_AW_PR_HEAD_REPO` env plumbing for fork-PR-aware safe-outputs handling.
- Older security-hardened container images (`gh-aw-firewall 0.28.1`, `mcpg v0.4.9`, `github-mcp-server v1.9.0`) and misses the `v0.87.2`–`v0.87.10` safe-output validation / permission-derivation / credential-hardening fixes.
- OTLP telemetry env wiring removed — no practical impact since it isn't configured in this repo.

## Plan

1. Pin `GH_AW_VERSION` / `GH_AW_BUILD_VERSION` / `GH_AW_COMPAT_VERSION` to `v0.87.1` in `Makefile`.
2. Run `make compile` to regenerate all `.lock.yml` files and `.github/aw/actions-lock.json`.
3. Run `make lint` to validate.
4. Open a PR referencing this issue.
5. Track `github/gh-aw-threat-detection#1014` upstream and re-upgrade to a fixed gh-aw release once available, reverting this downgrade.

## References

- https://github.com/github/gh-aw-threat-detection/issues/1014
- https://github.com/github/gh-aw/pull/54111 (external threat detection enabled by default)
- https://github.com/elastic/ai-github-actions/pull/1974 (unrelated `mcp-scripts` fix, confirmed unaffected)

Update the GH_AW_VERSION, GH_AW_BUILD_VERSION, and GH_AW_COMPAT_VERSION pins in Makefile from v0.87.10 to v0.87.1. Run make compile to regenerate the 57 workflow lock files and .github/aw/actions-lock.json, then run make lint; done means compilation and linting pass with the downgraded compiler.

Written by the indexing model from the issue text.