fix(discover): honor an enclosing repo's .gitignore for a git-less subfolder

[AmirF194]

discover_impl only ever loaded .gitignore from repo_path itself (fixed for the first half of #510 by 3f754cf) and, when repo_path carries its own .git, from that repo's info/exclude. When repo_path is a subfolder with no .git of its own, the enclosing repository's root .gitignore was never consulted, so files the enclosing repo ignores (secrets, build output) get indexed and become searchable.

Added resolve_enclosing_git_root(): when resolve_git_common_dir(repo_path, ...) fails, walk up parent directories the same way git does from a subfolder, and load the first ancestor's .gitignore (plus its info/exclude, since is_git_repo becomes true once an ancestor is found). It's merged ahead of repo_path's own .gitignore so the more specific file still wins on conflict via cbm_gitignore_merge, matching git's shallow-to-deep precedence.

Added three tests: enclosing root .gitignore honored, enclosing info/exclude honored, and the indexed subfolder's own .gitignore still overriding the enclosing one on conflict. All three go red without the fix. Ran scripts/test.sh (every suite, ASan+UBSan) on this branch and it's fully green. clang-format is clean on both files; cppcheck/clang-tidy flag a couple of pre-existing things in compat_regex.c/cli.c/mcp.c that this diff doesn't touch, same result on plain main.

Fixes #510

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.