v1.108.151 — nested-worktree exclusion + per-worktree identity (#372)

Nested-worktree exclusion + per-worktree identity (#372)

Claude Code creates git worktrees inside the repo at <repo>/.claude/worktrees/<name>. Each is a near-duplicate checkout, and the indexer walked right into them (a linked worktree marks its root with a .git file, which the name-based skip list never matched) — inflating per-language counts by roughly (worktrees + 1) and silently burning the max_folder_files cap on duplicates.

Fixed

• Every discovery walk now prunes linked worktrees — a .git file whose gitdir: target lives under .git/worktrees/<name>. General fix: catches worktrees wherever they live, not just under .claude/worktrees/. Submodules (gitdir: under .git/modules/) deliberately do not match, so their indexing is unchanged. New nested_worktree skip reason flows into the persisted coverage contract.
• Watcher fast path gets the same boundary check, so a file-change event inside a worktree never lands in the parent index.
• Worktrees get their own index identity. Under git-root identity a worktree resolved through its shared origin to the parent's owner/name slot, so watch-claude and watch-all collided ("Index already exists at .../.claude/worktrees/..."). A linked worktree is now keyed by its own path (local/<name>-<hash>), and path-containment identity matching stops at worktree boundaries. The two watchers coexist out of the box.

Already-polluted parent indexes self-heal on the next full re-index. The extra_ignore_patterns: [".claude/worktrees/"] workaround remains valid but is no longer needed.

Reported by @bitfliq with a diagnosis that was correct on every count — thank you.

No INDEX_VERSION, schema, or tool-count change. Full suite: 5456 passed.