SARIF: emit relatedLocations for evidence sites and suppressions metadata

[bjcorder]

Problem

SARIF results currently carry evidence, mutation, and link references only as opaque IDs inside properties (evidence_ids, mutation_ids, ...), so GitHub code scanning and other SARIF viewers show a single location with no navigable pointers to the guard/mutation sites that justify the finding — reviewers must cross-reference the JSON report by hand. There is also no suppressions support, so acknowledged findings can't participate in standard SARIF suppression workflows.

(Note: stable partialFingerprints already exist — authmapStable et al. with a line-move stability test — so that part of SARIF fidelity is done.)

Current behavior

• coverage_result in crates/authmap-report/src/lib.rs (~line 2659) builds each result with ruleId, message, partialFingerprints, properties (ID lists), and a single locations entry from coverage_location. No relatedLocations, no suppressions.
• The ReportIndex already resolves evidence/mutation/link IDs to their records (spans included) for Markdown rendering — the data needed for relatedLocations is on hand at render time.

Proposed implementation

1. relatedLocations
   • For each result, resolve evidence_ids, weak_evidence_ids, and mutation_ids through the existing ReportIndex and emit relatedLocations[] entries reusing sarif_location(span), each with a message.text describing the relationship ("authorization evidence: @login_required", "linked mutation: prisma.user.update"). Cap the list (e.g. 10 per result) to keep SARIF size bounded on link-heavy routes; note truncation in properties.
   • Viewers (GitHub code scanning) render these as navigable "related locations" — direct review UX win with no schema risk.
2. suppressions
   • When the per-route suppression config (companion config issue) marks a finding suppressed, emit SARIF suppressions: [{ "kind": "external", "status": "accepted", "justification": "<reason>" }] on the result instead of dropping it. GitHub code scanning treats suppressed results per SARIF semantics, keeping alert history consistent instead of open/close churn.
   • If the config issue lands later, this issue can still land the plumbing behind an internal flag with tests, activated when suppressions exist.

Acceptance criteria

• SARIF results for guarded/linked routes include relatedLocations with correct URIs/regions and human-readable messages; cap + truncation behavior tested.
• Suppressed findings emit suppressions[] with the justification; unsuppressed results emit none (absent key, not empty array — match SARIF 2.1.0 expectations).
• Output validates against the SARIF 2.1.0 schema (extend the existing SARIF tests in authmap-report).
• Golden SARIF fixtures updated; docs/GITHUB_ACTION.md/docs/USAGE.md SARIF notes updated; CHANGELOG entry.

References

• crates/authmap-report/src/lib.rs (coverage_result ~2659, sarif_location, ReportIndex)
• SARIF 2.1.0 spec: relatedLocations, suppressions
• Companion: per-route suppressions config issue