cleanup(coverage): two line counters for the same buffer disagree by one on a trailing newline

[CaptainMittens]

Two places in internal/cbm/cbm.c count the lines of the same source buffer and disagree by one on any file that ends with a newline — which is nearly every file.

cbm_count_lines (around internal/cbm/cbm.c:1372) ignores a final newline:

if (src[i] == '\n' && i + 1 < src_len) {
    n++;
}

The inline counter that builds orig_lines for the preprocessed-line map (around internal/cbm/cbm.c:1772) counts every newline:

uint32_t orig_lines = 1;
for (int ci = 0; ci < source_len; ci++) {
    if (source[ci] == '\n') {
        orig_lines++;
    }
}

Nothing is broken today

The two feed different consumers. cbm_count_lines decides the parse_unusable 80% threshold, where being one line generous costs nothing. orig_lines sizes an array and bounds a loop, where being one line generous is the safe direction. Raised by review on #1941 as a maintenance risk, not a live defect.

Why it is worth closing

A file whose report claims to say honestly which lines are missing should not hold two different answers to "how many lines does this file have". The next reader who reaches for either counter has no way to know which convention they picked up.

Suggested fix

One helper, one convention, both callers on it — with the chosen convention written down in a comment beside the helper, since either answer is defensible and only the disagreement is not.

Related: #963, #1941.