ci(security): raise the codeql-gate wait from 45 to 150 minutes

[DeusData]

security / codeql-gate waits for the CodeQL run on the PR head, with a budget of 90 × 30s = 45 minutes. That is shorter than CodeQL actually takes on this repository, so the gate has been failing runs that had not failed.

Measurement

PR #1426, head 7b72652a:

CodeQL SAST started	15:41:44
CodeQL SAST completed, conclusion=success	17:46:05 (124 min)
Gate step started	16:52:58
Gate step gave up, BLOCKED: CodeQL timeout	17:38:44

The gate declared a timeout 7 min 21 s before the scan it was waiting for succeeded.

Blast radius — and what this does not cover

Five open contributor PRs are red on security / codeql-gate alone with every other check green. Checking each head SHA against the CodeQL workflow splits them into two different causes, and only the first is this bug:

PR	CodeQL run on head	cause
#1426	completed success	gate timeout — fixed here
#1769	completed success	gate timeout — fixed here
#1703	completed cancelled	gate correctly refused a non-success; needs a fresh scan
#1741	completed cancelled	same
#1742	completed cancelled	same

For the three cancelled ones the gate behaved correctly: it saw completed with a non-success conclusion and exited 1 immediately rather than waiting. Raising the budget does nothing for them — they need CodeQL re-run, most likely having been superseded by concurrency: cancel-in-progress: true in codeql.yml. That is a separate question and is not addressed here.

The change

seq 1 90 → seq 1 300, i.e. 150 minutes. The progress labels and the step name follow.

Scope (per the CI-change checklist)

• Gating: unchanged. codeql-gate blocks exactly what it blocked before. A genuine CodeQL failure still exits 1 on the spot rather than waiting out the budget — only the absence of a verdict waits longer.
• Cost: a waiting ubuntu-latest job, only in the case that used to fail outright. The job already declares timeout-minutes: 240, so the wait still cannot outlive its own job.
• Flake surface: reduced. This removes a false-negative class, it does not add one.
• Trigger scope: unchanged.
• Check name: unchanged. The context is the job name security / codeql-gate; only the step's display name mentions the number, so branch protection is unaffected.

What this does not do

It does not address why CodeQL takes ~2 h on a C codebase this size — build-mode: manual runs the full scripts/build.sh inside the analysis. Making the scan faster is the better long-term fix; this stops the bleeding without pretending to be that.

Note on the commit message: it states that five PRs were red "for scans that passed". That is accurate for #1426 and #1769 only; the other three were cancelled scans, as the table above records. The table is the correct account.

[DeusData]

Replaced by #1960, which carries the identical diff (verified byte-identical: both produce SHA-256 d70f8b3f973e87eb741bd706a2b9beb71d9920cf05e731f537b32ebf64742961) with a corrected commit message.

This PR's commit message claimed five PRs were red "for scans that passed". That holds for #1426 and #1769 only. #1703, #1741 and #1742 are red on the same check for a different reason — their CodeQL run on head is completed=cancelled, so the gate saw a non-success conclusion and correctly refused without waiting. Raising the budget does nothing for those three.

Reopened rather than amended so the inaccurate claim does not persist in git log.