Add a 'What bomdrift catches that other tools miss' comparison page

[Metbcy]

Context

The v0.7 competitor research surfaced bomdrift's differentiator: pre-disclosure supply-chain risk signals (typosquat / maintainer-age / version-jump) that complement-rather-than-overlap the pure CVE focus of incumbents (Snyk, Trivy, Grype, OSV-Scanner). But there's no public artifact showing this in action.

A page that takes a handful of real historical supply-chain incidents and shows whether bomdrift's signals would have caught them at PR-review time — before the incident became a CVE — would be high-leverage for adoption decisions.

Scope

New docs page at docs/src/comparison.md (linked from SUMMARY.md):

• 3-5 case studies of real published supply-chain incidents (e.g. event-stream / ua-parser-js / colors.js / xz backdoor / node-ipc protestware / a recent typosquat). Each case:
  • The package + version that was compromised.
  • The CVE/GHSA ID (if assigned).
  • When bomdrift's signals would have caught it pre-disclosure (typosquat? young maintainer? major version jump? unusual license change?).
  • When other tools caught it (was it in OSV/GHSA? When? CVE issuance lag?).
• A summary table comparing "what bomdrift catches" across signal types vs the same dimension for 2-3 widely-deployed competitors.
• Methodology note at the end — how the comparison was done, what fixture SBOMs were used, where to reproduce it.

Include enough rigor that a CISO can verify the claims: cite issue tracker links, list the bomdrift CLI invocations used, link to fixture SBOMs (could live in tests/fixtures/comparison/).

Acceptance criteria

• docs/src/comparison.md exists with at least 3 case studies + summary table + methodology note.
• SUMMARY.md linked.
• Cross-referenced from README's Comparison table.
• No claims unsupported by the methodology note.

Tone

Honest. Where bomdrift would NOT have caught an incident (e.g. malicious code in an established package with stable maintainers), say so. The credibility of the page depends on it not over-claiming. Honest "we'd catch this; not that" beats marketing copy.

A note on commit signing

main requires verified signatures (the repo ships cosign-signed releases — we hold our own commits to the same bar).

You usually don't need to set up signing as a contributor — when a maintainer merges via "Merge" or "Squash", GitHub auto-signs the resulting commit and your unsigned PR-branch commits are fine. The friendlier path for everyone.

If you'd like your individual commits to land verbatim on main (so your name shows up in git blame), set up local signing once and your PR can be rebase-merged:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

Then add the same SSH public key under GitHub → Settings → SSH and GPG keys → Signing keys.

See CONTRIBUTING.md → Commit signing on main for the full picture. Either way, please don't sweat it — if your PR is otherwise great, the maintainer will pick a merge mode that works.