Noir::SkippedFiles

Every path by which a scan can quietly lose coverage, funnelled into one place.

AnalyzerFailure covers the case where a whole analyzer raised: coverage lost by the tech. The other half of the same problem is a single file raising inside an analyzer that otherwise completed — the per-file rescues in Analyzer#parallel_analyze and Analyzer#scan_files exist precisely so one unreadable or unparsable file costs only itself. That is the right behaviour, but until now the only trace was a --debug line, so the result of a scan that silently dropped a file was byte-identical to one that read everything.

#2612 made that gap wider by adding a ceiling on parse time: a pathologically malformed file now raises and is skipped where it used to take the process down. Loud-and-fatal became quiet-and-partial, which is the better failure mode only if the "partial" part is visible somewhere.

The analysis pass was only ever half the story, though. A scan drops coverage in six other places — an unlistable directory takes its whole subtree, an oversize or unreadable or binary-looking file is filtered out, a symlinked tree is never walked, an export never lands, -P runs with zero rules loaded — and each of those had its own local counter, its own log line, and no route into errors at all. So --strict (documented as "exit 2 if any analyzer failed or skipped a file") reported green on a scan that had lost most of a codebase.

Rather than six more counters, they all record here. failures is the one list, errors in the output is that list, and degraded in the CLI is "that list is not empty". Adding a seventh drop path is a record call.

Tallied rather than listed one entry per file: a repository that trips this usually trips it in bulk (a vendored minified bundle, a generated tree), and errors is part of the JSON/YAML/TOML output — one entry per tech with a count and a few example paths says the same thing without letting a broken checkout print thousands of lines.