Incremental sync ignores Git type changes (T), leaving stale rows authoritative #144

Found during review of #143. This behaviour already exists on `main`; #143 did not introduce it.

Problem

`ChangeDetector._parse_git_status_line` in `mcp_server/indexing/change_detector.py` handles `A`, `M`, `D` and `R*`, but ignores Git's `T` (type change) status. Separately, the staged committed snapshot in `mcp_server/storage/git_index_manager.py` excludes symlinks and gitlinks (submodules).

Reproduction (reported by the reviewer)

1. Index a repository that contains a regular file, `lib.rs`.
2. Commit a change that turns `lib.rs` into a symlink. `git diff --name-status` reports `T lib.rs`.
3. Run an incremental sync.

What happens: the change set is empty. The sync still publishes `incremental_update` and advances the indexed commit, but keeps the old `lib.rs` file, symbol and chunk rows. Search then returns content that is no longer in the tree, presented as authoritative. Turning a regular file into a submodule behaves the same way.

Proposed fix

• Parse `T` changes and treat each one as a delete plus an add. The add is admitted only if the new tree entry is something the index stores: a regular file that passes the supported-file and committed-snapshot rules. A symlink or gitlink entry becomes a delete only.
• Add tests for regular file → symlink, symlink → regular file, regular file → gitlink, and gitlink → regular file, in both incremental and full sync.

Acceptance

• After any type change, the published generation has no rows for content that is not in the committed tree.
• A file that becomes indexable through a type change is indexed.
• Every other sync behaves exactly as before.

🤖 Generated with Claude Code