Intermittent CodeQL `Analyze (go)` Autobuild runner termination blocks merges, and GitHub refuses to re-run it

> 🤖 Generated by the Agentic Engineer

## Evidence

Measured 2026-08-29 03:36Z across every open PR, with a `main` control:

| PR | `Analyze (go)` |
|---|---|
| #6742 | success |
| #6764 | **failure** |
| #6765 | **failure** |
| #6766 | success |
| `main`, 5 newest settled runs | success ×5 |

So it is **intermittent, not systemic** — same code, both outcomes. The failing job's annotations are
cgo extraction errors, not analysis findings:

```
could not import C (no metadata for C)
cannot convert w.window (variable of Pointer type pointer) to type windowPointer
```

## Why this blocks merges

`main` carries a **`code_scanning` ruleset rule** (`CodeQL: alerts=all, security=all`) in addition to
`required_status_checks` (`CI - Required Checks`). A run that fails to produce Go results therefore
gates the merge even though `Analyze (go)` is **not** in the required-status-checks list. That
distinction is easy to miss: reading only `required_status_checks` suggests CodeQL is advisory, and it
is not.

Both affected PRs sit `BLOCKED` with every other check green — including #6764, a **release** PR with
auto-merge already armed, so this stalls the release train rather than one feature.

## Why it does not clear itself

The analysis is GitHub-**managed** (`event: dynamic`, `path: dynamic/github-code-scanning/codeql`), so
there is no workflow file in the repository and `gh run rerun` is refused outright:

```
This workflow run cannot be retried
```

The only way to get a fresh analysis is a **new head commit**. For a bot-authored release PR nothing
will produce one, so it can sit blocked indefinitely.

## Expected

An intermittent extractor failure should not permanently block a merge, and recovering from one should
not require inventing a commit.

## Acceptance criteria

- [ ] Root-cause the cgo extraction failure (which package pulls cgo into the Go analysis, and whether
it can be excluded from CodeQL's build without losing coverage of first-party code).
- [ ] Either stabilise the analysis, or move off default setup to an advanced-setup workflow so the run
lives in this repository and **can** be re-run.
- [ ] A blocked PR has a documented recovery path that does not depend on an empty commit.
- [ ] Confirm the intended `code_scanning` rule behaviour is what we want for an extractor *error*
(as opposed to a real alert).

## Size

Medium. The diagnosis is bounded; the remedy is likely the default-setup → advanced-setup move, which
is a known, reviewable change.