Multi-line JavaScript statements (like res.json({...}) spanning lines 14-20) only showed coverage on their first line. The rest appeared as gaps in the coverage UI — neither covered nor uncovered.

Root cause

coverageProcessor.ts extracts line coverage from Istanbul's statementMap, which has start and end line/column pairs for each statement. The code only read stmtMap.start.line, ignoring stmtMap.end.line:

// Before — only first line
const line = String(stmtMap.start.line);
lines[line] = Math.max(lines[line] ?? 0, count);

Fix

Expand each statement to all lines in its range, and process statements largest-first so inner (more specific) statements override outer ones. This handles the key edge case: a try-catch block (covered, count=1) contains a catch body (uncovered, count=0) — the catch body must stay uncovered even though it's inside a covered range.

Extracted the logic into a standalone extractLineCoverage() function for testability.

Impact on coverage numbers

Tested on example-express-server:

• Before: 81.2% (52/64 lines) — many lines invisible
• After: 87.8% (144/164 lines) — correct, all lines tracked

The total coverable lines increased from 64 to 164 because continuation lines of multi-line statements are now counted. The percentage changed because both covered and coverable increased proportionally.

Review notes

• Python SDK is not affected — coverage.py reports individual lines natively
• TypeScript works correctly because the fix operates on Istanbul's output (post-source-map), not raw V8 data
• The overlapping statement sort (largest-first) is the critical detail — without it, outer covered statements would incorrectly mark inner uncovered catch blocks as covered