fix(codeql): resolve extension-backed SARIF rule severity instead of silently passing #2150

Reproduced fail-open severity lookup

Owner source: .github@64f483db9d052322c65bcdf1675d66138156f306, scripts/ci/codeql_sarif_gate.py, loaded by codeql-scan-dispatch.yml at WORKFLOW_SHA. gather_findings passes only tool.driver.rules to _finding_from_result; it never resolves result.rule.toolComponent or tool.extensions.

Actual current CodeQL artifact: run34741745981, Python artifact10312957919, consumer fast-mlsirm#1852 head 17ac3c9b41f30018915ade86d51dab146607bb88. The artifact has 0 driver rules, 43 rules in extension codeql/python-queries, and 2 results. Each result references rule={id: py/incomplete-url-substring-sanitization, index:17, toolComponent:{index:0}}. Referenced rule has security-severity=7.8, security/CWE tags, default level warning.

Read-only reproduction with the exact downloaded owner helper and actual artifact:

• _finding_from_result(result, tool.driver.rules) as production does: 0 gated findings across the 2 results.
• Control passing the actual referenced query-pack rules to the unchanged function: 2 gated findings.
• Hosted log independently says CODEQL_SARIF files=1 results=2 medium_plus=0.

The helper loses both severity and security tags by looking in the wrong component. These particular results are source-reviewed document DOI-presence false positives (fast-mlsirm#1838), but that classification does not fix the gate: a genuine security result represented through an extension can take the same fail-open path. No source security exploit or impact across every run is claimed. Central terminal status publication also failed403; that is separate (#1929).

Required owner repair

Use the existing canonical helper and tests, preserving default-branch governance and scanner/query configuration. Resolve SARIF reportingDescriptorReference against the correct tool component (driver when absent; referenced extension when present), including supported index/GUID/name identity and rule index/id validation. Do not flatten all components into one ID map: colliding rule IDs must remain distinguishable. Missing, malformed or inconsistent security metadata must not silently become a clean result. Validate suppression states rather than treating arbitrary presence as accepted suppression when investigating that adjacent branch.

Acceptance: real extension-backed artifact RED->GREEN; driver-backed results unchanged; component/rule ID collisions; invalid component/rule indices and mismatched identities; result-level severity override; valid accepted suppression versus unreviewed suppression; no-result and malformed input behavior. Existing helper's language/test framework remains Python. Run exact-head central checks and a real dispatch canary proving the hosted counter follows the referenced severity. False-positive handling remains separately reviewed, not global exclusion or consumer assertion removal.

Owner: dedicated ContextualWisdomLab/.github CI/security writer. Consumer supplied read-only source+artifact reproduction; no central mutation, competing PR, credentials or policy changes. Internal triage target and next review: 2026-09-13 12:00 UTC, because this is an observed security gate omission. No promised fix date or provider commitment. Evidence held in fast-mlsirm .codex/product-loop-20260912/: downloaded helper/workflow at64f483, actual SARIF archive, raw central run archive. Please coordinate a bounded owner repair and return exact source/test/canary evidence.