fix(search): use NUL-separated filelist + xargs -0 for paths with spaces

[lg320531124]

Problem

search_code returns 0 matches when the indexed repo path contains spaces (e.g. /Users/name/My Project/).

Root cause: write_scoped_filelist() writes newline-separated paths, and xargs splits on whitespace — so a path like /tmp/test repo/src/main.c becomes two arguments: /tmp/test and repo/src/main.c.

Fix

• write_scoped_filelist(): write NUL-separated paths via fwrite() instead of fprintf() with newline separators
• build_grep_cmd(): add -0 flag to xargs so it reads NUL-terminated entries

Non-scoped mode was already safe (root_path is single-quoted in the grep command: grep -rn ... '%s').

Verification

Indexed and searched a repo at /tmp/test repo/ — search_code now returns correct results:

{"results":[{"node":"main","qualified_name":"tmp-test-repo.src.main.main","label":"Function","file":"src/main.c","start_line":2,"end_line":5,"match_lines":[3]}],"total_grep_matches":1,"total_results":1}

Previously: 0 matches.

Closes #687

[DeusData]

Huge thanks for opening this PR and for the work you put into it.

The maintainer shop is currently full, so this may sit for a bit before it gets a proper review. We will come back to this as soon as possible with real feedback; I wanted to make sure it did not sit unacknowledged in the meantime.

[DeusData]

Thank you @lg320531124 — you correctly root-caused #687, and the fix concept is exactly right: a newline-separated filelist + plain xargs splits on spaces, while NUL-separated records + xargs -0 keep each path a single argument (and you correctly kept newline for the Windows PowerShell Get-Content -LiteralPath path). No command injection either — filenames flow through the filelist to xargs, never a shell.

One issue kept it from merging as-is: the filelist writer builds each record in a fixed char buf[CBM_SZ_2K] (2048) with unbounded memcpys of <root> + / + <file> + separator. Indexed entries are absolute paths, and on Linux PATH_MAX is 4096 — so a long workspace root + nested path exceeds 2048 and overflows the stack buffer (a memory-safety regression that's actually worse than the 0-matches bug, and green CI didn't catch it because no test exercises a long path).

I've distilled your fix into #751 (3dd2471), co-authored with you: same NUL / xargs -0 approach + your Windows newline branch, but the record is written piece-by-piece with fwrite/fputc (no fixed buffer, safe for any length), plus a reproduce-first test that indexes a repo under "<tmp>/my project" and asserts the match is found (RED before → GREEN after). Full suite green.

Closing as superseded by the distilled PR, with full credit to you. Really appreciate the correct diagnosis. 🙏