ci: adopt the shared osv-scan lane (infra#104)

[bdelanghe]

Byte-identical copy of templates/deps.yml pinned to osv-scan.yml@162accb, verified with diff. Adopted at hard-fail (ci-workflows#15).

Real coverage — and the first crates.io repo

This repo carries Cargo.lock, so green will mean "scanned and clean", not "nothing to scan". It's also the first crates.io repo in the rollout — every finding so far has been npm, either via package-lock.json or a deno lock's npm section.

If it reds

REMEDIATION.md — rung 1 first (cargo update -p <crate> --precise, no manifest change), stop at the first rung that works, don't skip to an acceptance.

One caution carried over from fold-engine#20: check the lock's entry count before and after any relock. There, a plain deno install produced a lockfile that scanned green by dropping the graph from 52 npm entries to 7 — the findings disappeared because the packages disappeared. A shrinking lock isn't a fix, it's a false green.

---

Generated by Claude Code

[bdelanghe]

Pushed a fix for all five findings. Two things need flagging: one about how I verified, one pre-existing in this repo.

The findings — first crates.io ones of the rollout

advisory	crate	locked	fixed
RUSTSEC-2026-0190	anyhow	1.0.100	1.0.103
RUSTSEC-2026-0007 (5.5)	bytes	1.11.0	1.11.1
RUSTSEC-2026-0008 (2.7)	git2	0.20.2	0.20.4
RUSTSEC-2026-0183	git2	0.20.2	0.21.0
RUSTSEC-2026-0184	git2	0.20.2	0.21.0

git2 carries three advisories across two fix lines — the target is 0.21.0, not the 0.20.4 the first row suggests.

Rung 1, then rung 2 for one crate only

cargo update cleared anyhow → 1.0.104 and bytes → 1.12.1, and took git2 to 0.20.4 — enough for -0008 but not -0183/-0184. Under cargo semver 0.20 → 0.21 is breaking, so the declared git2 = "0.20" couldn't reach it.

So rung 2 for git2 alone: "0.20" → "0.21". The other two stayed at rung 1 — only the crate that actually needed a manifest change got one.

The lock shrank 106 → 97, and here that's fine

I checked rather than assumed. The nine that vanished are all cfg-gated Windows/wasi crates (windows_*_msvc, windows_*_gnu, wasip2, wit-bindgen), dropped because windows-sys collapsed from two versions to one. No crate carrying an advisory disappeared.

Worth contrasting with fold-engine#20, where a shrinking lock meant the opposite: the vulnerable subtree itself vanished and the scan would have gone green by omission. Same symptom, opposite meaning — so the rule for REMEDIATION.md is check which entries left, not just compare counts.

Pre-existing: this crate doesn't build on main

Unrelated to this PR, and present before and after my change:

error: 9 positional arguments in format string, but there are 8 arguments
  --> src/script.rs:72:19

I left it alone — it's not a dependency issue, and guessing the intended argument would be inventing behavior. But it's worth knowing, and it does limit verification here: a clean build can't confirm the git2 0.21 API bump. What I can say is cargo check reports exactly that one pre-existing error and no git2 call-site errors, so nothing suggests the bump breaks the API. Happy to fix the format string in a separate PR if you want it.

All three resolved versions verified clean against api.osv.dev directly.

---

Generated by Claude Code