codedb: stale index when reviewing PR branches / switching git refs

[justrach]

Problem

When reviewing PRs locally (e.g. gh pr checkout 109), codedb continues serving the cached snapshot from the previous branch. Tools like codedb_outline, codedb_search, and codedb_symbol return results from main instead of the checked-out PR branch.

This makes codedb unreliable during PR review workflows where you frequently switch between branches or have conflict markers in files — the index doesn't reflect what's actually on disk.

Steps to reproduce

1. Have codedb indexed on main
2. gh pr checkout 109 (switches to a PR branch with new files/changes)
3. codedb_outline src/explore.zig — returns outline from main, missing the PR's new parser functions
4. codedb_search "parseHclLine" — returns no results even though the function exists on the current branch

Expected

codedb should detect that the working tree has changed (branch switch, rebase, conflict state) and either:

• Automatically re-index, or
• Warn that the index is stale and suggest codedb_index

Possible approaches

• Watch for HEAD changes (.git/HEAD or ref symlink)
• Compare snapshot timestamp against last checkout/rebase time
• Add a --watch mode that re-indexes on filesystem changes
• At minimum, show a staleness warning when the indexed commit doesn't match HEAD

[VesterDe]

This might be the one thing preventing me from giving codedb a go, I switch branches constantly.

[justrach]

Fixed in PR #159 — incremental file watcher now checks git HEAD every 2s. On branch switch/checkout/rebase, triggers full re-scan: removes stale files from old branch, re-indexes all files on new branch. Respects 15k trigram cap on rescan.