coverage: unresolved TS/JS/Python imports are dropped silently; only Rust discloses them #183

Symptom

Independent reviews of #181 and #182 (2026-09-04) both hit the same thing: when a TypeScript, JavaScript, or Python import cannot be resolved to a file, the edge is dropped and nothing in --deps, --importers, or the JSON coverage block says so. Only Rust emits a note (rustCoverageNote in scanner/rustgraph.go).

Reproductions from the reviews:

• .mjs -> .mts and .cjs -> .cts specifiers (not covered by fix(scanner): Resolve TypeScript ESM specifiers that name emitted files #182): --deps prints "5 files · 5 functions · 0 deps" with no note.
• Python: an over-climbing relative import or an unmatched relative target resolves to nothing with coverage_status: complete.
• .cjs is absent from the extension map (scanner/types.go:182-184), so CommonJS .cjs files are invisible with no disclosure.

Why it matters

The README promise is "tells you when it doesn't know." #174 made that true for symbol-level languages; #180's collide verdict and the hosted collision report both key off coverage_status. A file-level language that silently drops edges still reports complete, so a consumer cannot tell a checked-and-empty answer from an unchecked one.

Proposed fix

Count unresolved local-looking specifiers per language during graph build (relative paths, alias-matched paths, and .js/.mjs/.cjs/.jsx specifiers that matched no file) and, when the count is non-zero, append a partial source naming the language and count, following the Rust pattern. Third-party package specifiers are not "unresolved" and must not trigger it. Fixture per language; a test that the note appears for the .mts case and does not appear for a clean project.

Related: #148, #174, #181, #182, #172.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TcyheQmM3HCvxF5wRL3s5t