SARIF output and line-independent finding fingerprints, so a repository can adopt the check without being clean first

[raeq]

Summary

Two related additions on top of a scanner: a SARIF 2.1.0 writer, so findings land in
GitHub's Security tab and as annotations on the pull request that introduced them, and
stable finding fingerprints, which are what make a baseline file possible.

SARIF is the small half. The fingerprint rule is the part worth having even if SARIF never
ships.

Fingerprints that survive an edit

The naive fingerprint is file plus line plus character, and it breaks on the first commit
that inserts a paragraph, because every finding below the insertion point looks new. The
rule that works is file, character, and which occurrence of that character this is —
never the line number. Inserting text above a finding then does not raise a second alert
for it.

The honest limit belongs in the docs alongside it: two occurrences of one character in one
file are told apart by their order, so inserting a second occurrence above a recorded
first accepts the new one and reports the old. The count stays correct and nothing is
silently dropped, but which occurrence is named can swap.

Why a baseline matters more than it sounds

A repository with years of history will not be clean on its first scan, and requiring it
to be clean before the check can be turned on is the order that stops adoption. Recording
what exists today and failing only on what arrives afterwards is what lets a check go on
at all:

disarm scan --write-baseline .
disarm scan --fail --baseline .disarm-baseline.json .

A baselined finding is counted and not shown. When one is fixed, its entry is reported as
stale rather than quietly kept, so the file shrinks as the repository is cleaned instead
of accumulating acceptances for findings that no longer exist.

Mapping findings to SARIF levels

AnomalyKind needs an ordering it does not currently have. A reasonable first cut:

level	kinds
error	a decoded payload
warning	bidi, control, mixed_script, compat_fold, zalgo
note	anything reported but not actionable

That ordering does not exist in the library today — AnomalyKind is a flat enum with no
severity — so this issue either introduces one or the writer hard-codes the mapping. The
first is more useful and belongs in the library rather than the CLI.

Scope

1. A --sarif output mode, mutually exclusive with --json.
2. Fingerprints per the rule above, with the ordering caveat documented.
3. --baseline and --write-baseline, plus stale-entry reporting.
4. Decide whether severity belongs on AnomalyKind in the library. If it does, that is a
   public API addition and should be its own change.
5. A documented GitHub Actions snippet, including the detail that the upload step must run
   before any failing exit or it never runs at all.

Depends on #704; nothing here is buildable without a scanner.

---

Found while comparing disarm against juriku/untrace,
which ships all of the above; the fingerprint rule and its stated limitation are taken from
there. AnomalyKind having no severity field was read from src/anomalies.rs.