chore(ci): bump the fleet nox pin to 1.19.0

[felixgeelhaar]

nox shipped 1.17.1, 1.18.0 and 1.19.0 in two days, leaving the pin three releases behind. warden's own version-drift check refused a release push over the gap — correctly, and that is what surfaced this.

Measured before moving

Every repo with a committed .nox/baseline.json scanned under both 1.17.0 and 1.19.0, comparing net-new critical/high — the exact condition the shared gate fails on. The control is the point: counting failures under the new version alone conflates "this bump breaks it" with "already broken".

25 repos identical · 0 regressions · 4 improved

Repo	1.17.0 → 1.19.0
axi-go	1 → 0	SEC-147 gone — the Resend pattern matching re_ inside a Go identifier (Store_Loads…)
nomi	11 → 5	SEC-240 (matched a Go comment) and SEC-435 ("ghs_fake_install_token") gone
lexora	ERR → 0	-format now honoured over output.format in config
nexa	ERR → 0	same

Three of these are fixes for issues filed against nox this morning (Nox-HQ/nox#361, #362).

The lexora/nexa change is the most consequential. Under 1.17.0 a repo-level output.format: sarif silently overrode the workflow's own -format json,sarif, so findings.json was never written and the gate step — guarded on that file's existence — skipped, which in Actions reads as a green check. Those two repos were passing a gate that never ran. 1.19.0 honours the flag, so the class of failure disappears at the source rather than only being caught by #47.

Sha verified in both directions

Before changing it, I confirmed the outgoing value against 1.17.0's published checksums.txt:

published 1.17.0 : 1a7af79d12015e929925effdc428f034cc53f64be2a9099a6706c9e982a06e26
pinned in go-ci  : 1a7af79d12015e929925effdc428f034cc53f64be2a9099a6706c9e982a06e26   MATCH
incoming 1.19.0  : 9d1029a686bd8df3477ef3034d65ab477631e7b2cdfee385e2b20295ffe834b8

That confirms the field and the method rather than assuming them. Each of the three workflows asserted exactly one occurrence of the old version and one of the old sha before rewriting, and all three parse with a duplicate-key-rejecting loader — yaml.safe_load accepts duplicates silently and would not have caught the breakage in #49/#50.

No remediation needed first

The standing rule is "remediation PRs first, then the central bump", to stop a bump creating net-new findings. Measurement shows this one creates none and removes six. The ordering does not bind here.

nomi's remaining 5 and keyward/episteme-api's counts are unchanged by this bump and tracked separately in #46.