Fix earlier prompts vanishing when a later prompt re-edits the same line

[EsmeYi]

Summary

Ranim reported: editing one line with three consecutive prompts (add, then edit, then a small tweak) made the earlier prompts disappear from the line's history entirely — not just lose the live highlight, gone from the "previously touched by" dropdown too.

Root cause: extractSnapshot() computed a snapshot's attributed lines, then dropped any line that got touched again before the target tree, and discarded the WHOLE Change object if nothing survived — before deduplicateAILines() ever got a chance to run. deduplicateAILines() already handles exactly this situation correctly (demoting an overridden line to a ghost line instead of erasing it), but only for Change objects that actually reach it.

Fix 1 — the in-progress (uncommitted) chain

For buildUncommittedChanges's direct call to extractSnapshot, this pre-filtering is redundant with deduplicateAILines() by construction: its targetTree is always exactly the chain's own last snapshot, so anything that "overrides" a line before targetTree is necessarily a later entry in the same chain — which gets its own Change object anyway. Added a dropOverriddenLines parameter, false for this call site, letting deduplicateAILines() do the correct ghost conversion instead.

Fix 2 — the same bug once the chain gets committed (self-review catch)

extractChangesFromSnapshotChain (used by buildCommittedHistory once the user runs git commit) calls extractSnapshot too, left at the default dropOverriddenLines=true — so the exact same bug still applied there: the history looked right immediately after several same-line prompts, right up until the user committed, at which point it broke again.

The true default is still genuinely needed for this path: targetTree there is a real finalized commit, which can include a last-minute manual edit made right before git commit with no AI turn (and so no Change object) representing it at all — that has to be caught somewhere.

Fixed by narrowing what counts as an "override" worth dropping for: only the gap strictly after the chain's own last snapshot, not the whole span from this snapshot to targetTree. A line touched by a later entry within the same chain already gets its own Change object and reaches deduplicateAILines() correctly; only what's left over past the chain's own tip is genuinely untracked. While rescoping this, also fixed the filter comparing mismatched tree coordinates (it compared an already-target-mapped line against the residual hunks' old/source side instead of their new/target side) — didn't affect the bug above, but was live and directly adjacent.

Test plan

• npm run compile / npm run lint / npm run test:unit (53 tests) clean
• Real git-based repro matching Ranim's report exactly (uncommitted): three consecutive prompts editing the same line — all three now appear, first two as ghost/history, third as live
• Same repro replayed through to a real git commit (previously broke again at commit time) — same correct result
• Genuine untracked manual edit made right before commit: single-line case (whole Change correctly disappears) and multi-line case (only the manually-edited line excluded, untouched lines stay attributed)
• Re-verified the AI-to-AI iteration (uncommitted) and cross-commit contested-line (committed propagation) scenarios are unaffected