feat(report): SARIF 2.1.0 emitter for CI / code-scanning integration

[seanturner83]

Closes #624.

What Problem This Solves

Strix emits CSV, Markdown, and JSON, but no SARIF — so findings can't feed
GitHub code-scanning, an ASPM, or any SARIF-consuming CI gate without a custom
converter. This adds a first-class SARIF 2.1.0 emitter.

The Change

A stdlib-only emitter (strix/report/sarif.py), written to findings.sarif
from ReportState._save_artifacts alongside the existing artifacts.

Design invariants (learned running this in production):

• Stable partialFingerprints.primaryLocationLineHash per finding, so a
  re-scan that re-words a title doesn't churn code-scanning alert IDs.
• Class/category hashing so the same vuln class maps to a stable ruleId
  across scans rather than drifting.
• Findings with no code location anchor to SECURITY.md with a synthetic
  marker instead of being silently dropped.
• Always emit (even with zero findings) so a clean re-scan overwrites a
  stale findings.sarif and code-scanning auto-resolves fixed alerts.
• tool.driver.version reports the strix package version.
• Fully isolated in its own try/except: a SARIF build error must never
  break the CSV/MD/run-record path.

No new dependencies; no behavior change to existing artifacts.

Testing

• Added tests/test_sarif.py (7 cases): basic 2.1.0 shape + real code location,
  always-emit on zero findings, tool_version reporting, locationless finding
  anchored (not dropped), fingerprint stability across a title rewording, and
  distinct findings getting distinct fingerprints. pytest tests/test_sarif.py
  → all pass.
• Validated the emitted document against the official OASIS SARIF 2.1.0 JSON
  schema (basic, zero-findings, locationless, and mixed cases) — all valid.
• Exercised end-to-end via a real scan: agent-discovered SQLi/command-injection/
  weak-hash findings → valid findings.sarif with real code locations and
  distinct per-CWE fingerprints.
• ruff check, ruff format --check, pyupgrade --py312-plus, bandit -c pyproject.toml all clean.
• (mypy not asserted: the repo's pinned pre-commit mypy hook errors out on the
  bundled openai SDK on main as well, independent of this change. Verified
  clean under mypy 1.17 with the repo's own config.)

[greptile-apps]

Greptile Summary

This PR adds SARIF output for Strix reports. The main changes are:

• New SARIF 2.1.0 report builder and writer.
• Integration with report artifact saving.
• Synthetic locations for findings without code anchors.
• Stable fingerprints and class hashes for code-scanning consumers.
• Repository provenance in SARIF runs when repo context is available.
• Tests for SARIF shape, fingerprints, PoC handling, atomic writes, and repo context.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

Important Files Changed

Filename	Overview
strix/report/sarif.py	Adds the SARIF emitter, location handling, fingerprinting, PoC metadata handling, fixes support, provenance fields, and atomic file writing.
strix/report/state.py	Adds SARIF artifact writing with isolated error handling and best-effort repository/version metadata.
tests/test_sarif.py	Adds coverage for SARIF output shape, empty runs, fingerprints, PoC metadata, fixes, logical locations, provenance, and atomic replacement.
tests/test_state_repo_context.py	Adds coverage for repository name parsing and repository context derivation from cloned repos.

_{Reviews (3): Last reviewed commit: "fix(report): complete SARIF code scannin..." | Re-trigger Greptile}

[rajpratham1]

Thanks for the comprehensive SARIF implementation. The overall design is solid, especially keeping SARIF generation isolated so failures don't affect existing report outputs, along with the extensive test coverage. My main concern is scope: this PR introduces nearly 1,000 lines including the emitter, integration, fingerprinting, synthetic-location handling, and supporting utilities, which makes review and long-term maintenance difficult. If practical, I'd recommend splitting future work into smaller logical PRs (emitter, integration, fingerprint improvements). Also, sarif.py has grown quite large and could benefit from extracting helpers (locations, fingerprints, rule generation) into separate modules. Otherwise the implementation looks thoughtfully designed.

[bearsyankees]

@greptile

[bearsyankees]

@greptile

[bearsyankees]

LGTM thanks @seanturner83 removed the zh reference