chunker: the last chunk ends at the file's last line, not one past it

[ekechinwokah]

chunkFile splits content on "\n". A file that ends with a newline, which is nearly every file, leaves a trailing empty string, so lines.length was the real line count plus one. Both span builders (fixedWindows and packSegments) end their last span at lines.length, so the last chunk's endLine, and the end_line stored in the index, ran one line past the file. On the bench repo MAX(end_line) was wc -l plus one for every file (Cargo.toml 443 vs 442, src/lib.rs 220 vs 219, README.md 554 vs 553). A hit's path:start-end citation for the last chunk pointed past the file, and any answer that read a file's length off MAX(end_line) was off by one.

Drop exactly one trailing empty element before computing spans. Blank lines ahead of the final newline are still lines; a CRLF file leaves the same empty element, so it is covered without changing the split. How tree-sitter definition rows map to lines (d.row + 1) and the empty-span guard are unchanged, and spans still tile the file.

The regression test covers fixed windows, tree-sitter, and markdown, with and without the trailing newline; it fails before this change.

Existing indexes keep the old end_line values until they are reindexed.