Nested git repositories are silently skipped by file discovery; --no-ignore has no effect #101

Environment

• zg 0.2.1 (npm), macOS
• Workspace layout: a meta-repo whose subdirectories are independent git clones (not submodules, no .gitmodules), listed in the meta-repo's .gitignore:

meta-repo/
├── .git
├── .gitignore # contains "services/" to keep git status clean
└── services/
 ├── service-a/ # independent git clone
 └── service-b/ # independent git clone

This "super-repo of clones" layout is common for multi-repo workspaces (similar reports exist for other agent/indexer tools).

Problem

zg index at the meta-repo root silently indexes none of the nested repos. The summary reports full coverage, and --debug shows no skipped entries for them — the nested trees are simply never scanned.

Reproduce

mkdir -p meta/services/service-a && cd meta
git init -q && echo "outer" > README.md && git add -A && git commit -qm init
cd services/service-a
git init -q && echo "NEEDLE_MARKER" > src.txt && git add -A && git commit -qm init
cd ../../..
zg index --embedding local/potion-code-16m-v2
# files: 1 scanned, 1 added — service-a/src.txt is missing
zg query --fts NEEDLE_MARKER # no matches
# Proof the boundary is the nested .git:
mv services/service-a/.git /tmp/git.bak
zg index --rebuild
# files: 2 scanned — NEEDLE_MARKER now indexed and searchable
mv /tmp/git.bak services/service-a/.git

What does not help

Related friction once you work around it with per-repo indexes

1. Upward root resolution trap: inside a nested repo without its own index, plain zg index (no positional root) resolves to the nearest ancestor workspace's manifest — i.e. the meta-repo — and silently re-indexes that instead. Building a child index requires zg index <absolute-child-path> --mode direct.
2. CLI indexed queries are cwd-bound: zg query routes via the nearest workspace from process.cwd(), so a query at the meta-repo root cannot reach child indexes; only the MCP tool's root parameter can select them.

Ask

• Allow indexing into nested git repositories, at least as an explicit opt-in (e.g. a --nested / --include-nested-repos flag, or honoring negation globs for directories containing a .git).
• If the boundary behavior is intentional, please document it and surface it in --debug output (e.g. skipped_file reason=nested_git_repo) so partial indexes aren't mistaken for full coverage.
• Longer term, a first-class multi-repo workspace (one root, many nested indexes, a single query surface) would remove the need for the per-repo workaround entirely.