bug: context snippet endLine is one past EOF for every file that ends with a newline

[aryamthecodebreaker]

Summary

Every context JSON snippet for a source file that ends with a trailing newline reports endLine one past the real end of the file. The snippet's own content field proves it: the content contains N lines while startLine: 1, endLine: N+1.

Any consumer that slices [startLine..endLine] inclusive emits a phantom empty line, and any consumer that bounds-checks ranges against the file rejects valid snippets.

Environment

• fixmap 0.9.0 (npm global)
• Windows (win32), Node v24.13.0

Repro

git init demo && cd demo
Set-Content package.json '{"name":"demo","scripts":{"test":"node --test"}}'
New-Item src | Out-Null
Set-Content src\widget.js "function makeWidget(){`n  // widget factory line2`n  return { size: 10 };`n}`nexport const WIDGET_TERMX = makeWidget;"
git add -A; git commit -m init

fixmap context --issue "WIDGET_TERMX broken" --format json --output ctx.json
Get-Content ctx.json | ConvertFrom-Json | Select-Object -ExpandProperty snippets

Actual

For src/widget.js, which has exactly 5 lines:

{
  "path": "src/widget.js",
  "role": "primary",
  "startLine": 1,
  "endLine": 6,
  ...
}

6 > 5 — past EOF.

Characterization

File ends with \n?	Actual lines	Reported endLine
yes	5	6
no	5	5

Minimal case from a separate run: a 1-line file reports startLine: 1, endLine: 2 while its content field holds exactly one line. The reported range counts the terminating newline as an extra line; stripping a single trailing line terminator before counting lines should fix all cases.

Expected

endLine is the 1-based number of the last content line (5 here). Alternatively, if the extra line is intentional, the schema/docs need to define the convention — but today the same release's content field disagrees with the range, so at least one of them is wrong for any consumer.