CodeQL: Analyze (go) never uploads results from the merge queue

## Problem

`Analyze (go)` has failed in every recent `merge_group` run of `codeql.yaml`:

| Queue entry | go | rust | js-ts |
|---|---|---|---|
| pr-611 | fail | fail | success |
| pr-587 | fail | success | success |
| pr-608 | fail | success | success |
| pr-600 | fail | success | success |
| pr-594 | fail | success | success |

The cause is documented in the workflow itself (`.github/workflows/codeql.yaml`): the merge queue deletes the temporary `gh-readonly-queue` ref before the job finishes uploading its SARIF, and the upload then fails with

```
##[error]ref 'refs/heads/gh-readonly-queue/main/pr--' not found in this repository
```

`continue-on-error: ${{ github.event_name == 'merge_group' }}` keeps that from blocking merges, which is the right call. The consequence is that the Go analysis in the queue is **pure cost**: it runs for 10+ minutes on every queue entry and its results are always discarded.

Rust normally finishes fast enough to beat the ref deletion. It only failed for pr-611 because that entry was ejected early by an unrelated `Vulnerability Check` failure (see #614), which deleted the ref about 68 seconds in.

## Why it is not a coverage gap

The same commit is analyzed by the `pull_request` trigger before it can enter the queue, and those results upload normally. So this is wasted runner time and a permanently red job in queue logs, not a hole in scanning.

## Options

- Skip the languages that cannot finish in time for `merge_group` (or skip CodeQL in the queue entirely) and rely on the `pull_request` analysis, which is what actually records results.
- Keep the run but drop the upload for `merge_group`, so the job reports honestly instead of failing.

Either way the current state is misleading: anyone reading a queue run sees a failed `Analyze (go)` and has to rediscover that it is expected.

Read .github/workflows/codeql.yaml first, focusing on the merge_group trigger, CodeQL language matrix, SARIF upload, and continue-on-error behavior. Compare the workflow with pull_request runs and the reported queue failures. Done means the chosen queue behavior is explicit, no expected Analyze (go) failure is misleading, and pull_request results remain available.

Written by the indexing model from the issue text.