fix(deps): clear the remaining 35 advisories, and unblind the scanner that missed them (#108)

[bdelanghe]

Closes #108. Discharges #89, #91 and #109.

The osv check on this PR is RED, and that is the result, not a failure to fix. Before this PR the lane was green while scanning nothing. Now it scans 446 packages and reports 11 real vulnerabilities. A red honest lane is the deliverable; see §3.

1. Clear the advisories the scanner was missing

package		advisories
rand	0.8.5 → 0.8.6	2 → CLEAN
wasmtime	18.0.4 → removed	28
wasmtime-wasi	18.0.4 → removed	5

#91 and #109 are discharged by deletion, not by bump, because nothing imports wasmtime. crates/xtask is the only workspace member declaring it, and its only references are Command::new("wasmtime") — shelling out to a binary — plus one string in a README template. The other use wasmtime:: sites are in crates/apps (not a workspace member) and crates/hooksmith-app (a member declaring no wasmtime dependency), so neither compiles. Dropping two .workspace = true lines removes 90 packages from the lockfile.

Bumping was the obvious move and is worse on every axis, because the version chase doesn't terminate anywhere useful:

18.0.4  (current)               28 advisories
24.0.7  (what #109 proposes)     7 advisories  — still not clean
47.0.3  (first clean release)   requires Rust 1.94; rust-toolchain.toml pins 1.88.0

Merging #109/#91 as proposed would have left 9 advisories behind, and reaching a clean version would have forced a repo-wide toolchain bump — to satisfy a dependency nothing calls.

2. Unblind the scanner (#108)

.gitignore listed Cargo.lock while the file is tracked. Git exempts tracked files, so the rule was inert and nothing looked wrong — but osv-scanner applies the pattern literally, skipped the repo's only lockfile, and --allow-no-lockfiles turned "scanned nothing" into a pass. Removed from both generator sites in crates/xtask/src/main.rs so the next gen-config doesn't put it back.

Measured, before → after:

before:  170 dirs, 1617 inodes, 0 Extract calls   No package sources found   No issues found
after:   171 dirs, 1616 inodes, 1 Extract calls   Scanned Cargo.lock, found 446 packages

3. What the honest scan found — and a prediction of mine that was wrong

This PR originally claimed the first real scan would come up green because §1 cleared everything. That was wrong, and the scan is what corrected it: I had only queried the five packages I already knew about, not the other 441.

run	result
first honest scan	18 vulnerabilities / 16 packages, 11 fixable
after the third commit	11 vulnerabilities / 9 packages, 4 fixable

The third commit clears the seven reachable by cargo update alone — anyhow, bytes, crossbeam-epoch, event-listener, slab, time, tracing-subscriber, all verified CLEAN at the resolved versions. time needed an explicit --precise: a plain update stopped at 0.3.44, three short of the 0.3.47 carrying the fix.

The 11 that remain are not reachable from this PR, and they split into two kinds that deserve different treatment:

Fixable, but real work (4):

• git2 0.18.3 → 0.21.0 — 3 advisories. 209 call sites across five members. A genuine migration.
• lru 0.12.5 → 0.16.3 — 1 advisory. Transitive under ratatui, whose range does not admit the fix, so it needs a ratatui bump first.

No fixed version exists (7): backoff, derivative, instant, number_prefix, paste, rustls-pemfile (both 1.0.4 and 2.2.0). These are unmaintained-crate advisories — precisely the case deps.yml documents osv-scanner.toml [[IgnoredVulns]] for.

Deliberately not suppressed here. An ignore entry is a judgement about accepted risk and wants its own review rather than riding along in a PR about a scanner bug. And suppressing the four fixable ones would be wrong whatever the lane says — that would recreate exactly the green-over-real-findings state this PR exists to end.

Verification

• cargo check --workspace --locked --all-targets passes. The 7 xtask warnings are pre-existing visibility lints in wasm_event_bus, untouched.
• Version claims are from the OSV API against versions read out of the lockfile, not from release notes.
• git check-ignore --no-index -v Cargo.lock now matches nothing; before, it returned .gitignore:7:Cargo.lock.
• Note on counting: the third commit message says "thirteen remain" where the scanner says 11. Both are right — the scanner dedupes aliased GHSA/RUSTSEC pairs (git2 and lru each have one), I counted the aliases separately. 11 is the number to quote.

Two things deliberately left alone

The @checksum: e902a214 header is stale and I did not fake a fix. It doesn't match the file's contents for any header offset, and did not before this change. gen-config --validate exits 1 with Error: No such file or directory, and no workflow validates it. Rather than write an attestation I can't reproduce, the stale value stays and is reported. Worth its own issue — a generated-file checksum that nothing checks and that is already wrong is the same shape as the scanner this PR fixes.

strict_file_validator.rs also lists Cargo.lock, but that's xtask's own file-audit skip list, matches *.lock regardless, and has nothing to do with osv-scanner.