[ata-sesli]

Summary

Fixes #114. The parallel indexing path now reads source files with the same 16 zeroed spare bytes as every other source reader. tree-sitter's lexer reads a few bytes past the last character, and those bytes now stay inside the buffer.

Problem

c023931 and 90e85bb changed every source reader to allocate size + 16 and zero the tail, because tree-sitter's lexer peeks past the end of the input (ASan reported it as a heap-buffer-overflow). src/pipeline/pass_parallel.c has its own static read_file, which neither commit touched. It still allocated size + 1.

That buffer is used in two places:

• the extract workers pass it to cbm_extract_file, the same tree-sitter parse the padded sequential reader feeds;
• the cross-file LSP pass re-reads files with it during resolve.

The parallel path handles every full index of more than 50 files with more than one worker, and incremental runs of more than 50 changed files. So the unpadded reader is the one most real indexing goes through.

Change

read_file in pass_parallel.c now does what pass_calls.c, pass_usages.c and the other readers do:

• allocate size + CBM_TS_LOOKAHEAD_PAD (16);
• clamp nread to size;
• zero the padding after the data.

The returned length is unchanged, and the buffer is still NUL-terminated right after the data. Callers see no difference.

The reader is still a copy of the others. Merging the copies is tracked in #110 (one pipeline path) and #113 (shared helpers).

Verification

• Full test suite with CBM_TEST_TIERS=all, macOS arm64: 6,447 passed, the same count as main (665f1d5).
• clang-format-diff (clang-format 22.1.8) is clean on the changed lines, and git diff --check passes.
• Not done: I did not reproduce an ASan report on the parallel path before the fix. No input is known that triggers the lookahead deterministically, and the original fix (c023931) added no test either. This change makes the parallel reader match the readers that fix already covered.