fix(scan): honor .codegraphignore on the git fast path

[andreinknv]

Summary

The .codegraphignore marker (per-directory opt-out from indexing) was respected by scanDirectoryWalk (the filesystem-walk fallback) but silently ignored by getGitVisibleFiles (the git fast path) and getGitChangedFiles (sync's git path). Same project gave different file sets depending on whether .git existed — typically the marker "worked" only on non-git scratch projects and was a no-op everywhere else, the opposite of how most users encounter it.

What changed

Two helpers in src/extraction/index.ts:

• findCodegraphIgnoredDirs(rootDir, files) — walks parent directories of the given file list, returns the set of dirs that contain a .codegraphignore marker. Walks once per unique parent directory with an early-out on shared ancestors.
• isUnderCodegraphIgnoredDir(filePath, ignoredDirs) — true if filePath lives under any of those dirs.

Applied at three sites:

• scanDirectory and scanDirectoryAsync — between the git file list and the include-pattern filter
• getGitChangedFiles — refactored to a two-pass collect-then-bucketize so the ignored-dir set is built once from the candidate paths

The marker file itself does not need to be tracked by git — fs.existsSync catches it whether it was committed or added as a local override.

Files changed

File	Change
src/extraction/index.ts	Add findCodegraphIgnoredDirs + isUnderCodegraphIgnoredDir; apply in scanDirectory, scanDirectoryAsync, getGitChangedFiles
__tests__/codegraphignore.test.ts	6 regression tests

Test coverage

• scanDirectory honors marker in a subdir on the git fast path
• Marker at project root excludes everything
• Marker in one subdir does not affect siblings
• Marker added as local override (untracked) is still respected
• Non-git fallback parity (sanity, pre-existing behavior unchanged)
• Sync (getGitChangedFiles) ignores changes inside marker dirs

Known limitation (pre-existing, out of scope)

If a .codegraphignore marker is added after files in that directory have already been indexed, the next sync via the git fast path won't proactively delete those stale rows — git status doesn't report unchanged files. The next full indexAll (or a sync that falls into the filesystem-walk path) will clean them up. This is an existing characteristic of the git fast path; documenting here for transparency rather than fixing in this PR.

Test plan

• npm test: 386/386 pass on macOS (one pre-existing fs.watch flake under parallel load, passes in isolation)
• npx tsc --noEmit clean
• Independent reviewer pass before pushing — verdict APPROVE; addressed two info-level cleanups (JSDoc accuracy, removed dead try/catch around fs.existsSync which never throws)

🤖 Generated with Claude Code