feat: replace the hand-rolled walker with the ignore crate (#22)

[hermanngeorge15]

Closes #22.

main::walkdir was a recursive read_dir with a five-extension allowlist and nothing else: it descended into .git, target and node_modules, ignored .gitignore entirely, read files of any size fully into memory, and used is_dir() — which follows symlinks — with no loop guard.

Measured, release vs release

	this repo	ecosystem tree (8 repos)
before	100 ms	1.46 s
after	10 ms	0.31 s

The findings that disappeared are the point

On this repo the count goes 159 → 129. All thirty came from four gitignored scratch files — review reports quoting attack strings, which nobody would act on.

$ injection-scanner check . --no-ignore
159 finding(s): 108 critical, 51 high

Exactly 159 back. That's the check that this removed noise rather than coverage, and it's the assertion I'd want a reviewer to push on hardest.

What's in it

• ignore crate (the ripgrep walker) — .gitignore support and parallel traversal.
• Flags: --exclude, --include, --no-ignore, --max-file-size, --follow-symlinks, --jobs.
• Unconditional deny-list for build output, not lifted by --no-ignore and not reachable by --include. "Don't trust this repo's ignore rules" is a reasonable thing to want on a checkout you didn't write; "scan 40,000 files of build output" is not. Both pinned by tests.
• require_git(false) — otherwise the same directory gives different answers scanned as a checkout vs. as an extracted tarball. Coverage that depends on whether .git happens to be present is coverage you can't reason about.
• Sorted results — parallel traversal finishes in thread order, and the JSON output is an array consumers diff.

Nothing is skipped silently

Files the walker reached and declined are counted with their reason. Ignore rules prune whole subtrees before the walker sees them, so they can't be itemised without giving up the speed — those are disclosed as having been applied instead:

note: .gitignore rules were applied — paths they exclude were not scanned and are
      not counted above. Use --no-ignore to include them.
note: 27 file(s) not scanned — not a scanned file type. Use --include <glob> to add them.

A skills pack shipping a .gitignore containing * would otherwise scan nothing and report a clean bill of health — the same failure mode this milestone has been closing everywhere else.

Extensions are deliberately unchanged

Widening them is #23. 209 of the 215 files it would newly reach on this repo are under target/, which is why it needed this first — as the issue predicted. Doing both at once would also make it impossible to tell a walker regression from a file-type regression.

Also fixes the #19 harness guard

It flagged two of the new tests. It matched target/debug as a substring, so a fixture directory named that — created to prove the walker refuses to descend into one — read as a test mis-targeting the binary.

Now it requires the binary name on the same line, and adds the direct check the original lacked: a file that spawns Command::new must mention CARGO_BIN_EXE somewhere in it. File-level, because going through a local binary_path() helper is the correct shape — a per-line rule would have condemned the very fix the guard exists to protect. Both branches mutation-checked against deliberate offenders.

Tests

11 new, one per defect the old walker had: deny-list, deny-list under --no-ignore, .gitignore round-trip, size cap, symlink loop, unscanned-type accounting, --include, --include vs deny-list, --exclude, deterministic ordering, unreadable subdirectory. Full suite: 18 binaries green, clippy clean.

Merge order

Touches src/main.rs's Check args, so this conflicts with #65 (which adds --strict / --min-confidence there). Trivial to resolve either way — happy to rebase this one on top once #65 lands.