Potential risk: .trim() removal in scan-project.mjs may mishandle paths with trailing spaces (commit b4d856d)

[kapil971390]

Bug Report

Commit: b4d856d — fix(scan-project): preserve non-ASCII path bytes via git ls-files -z

---

What was fixed

The PR correctly fixes silent file drops for non-ASCII paths (emoji, accented chars, CJK) by switching to git ls-files -z (NUL-terminated output) instead of newline-separated output.

Remaining risk

The fix removes .trim() entirely alongside the delimiter change:

// Before
.split("\n").map(s => s.trim())

// After
.split("\0")

This is correct for non-ASCII paths — but it also means file names with legitimate trailing spaces (e.g. file .txt) are now preserved with their whitespace, whereas before they would have been silently trimmed.

If any downstream consumer does a string equality check or file lookup against a path without accounting for trailing spaces, it will silently fail to match.

Steps to verify

# Create a file with trailing space in the name
touch "test file .txt"

# Run scan-project
# Before fix: path returned as "test file.txt" (trimmed — wrong but consistent)
# After fix:  path returned as "test file .txt" (raw, correct — but downstream must match exactly)

Suggested safeguard

Replace the blanket .trim() removal with a targeted empty-entry filter only:

.split("\0").filter(p => p.length > 0)

This keeps NUL-split behavior while making it explicit that only the trailing empty entry is dropped — not legitimate whitespace.