A way out of the conflict, not just a warning

[jamescrosswell]

Context

Fourth slice of #133. #267 gave the conflict modal Overwrite and Cancel. Cancel is safe but it's a dead end: you're told the two versions diverged and left to work out what to do about it somewhere else. This slice gives you the two ways out — see the difference, or take theirs.

Depends on #269 (and transitively #268, #267): Reload is #269's reload path, asked for deliberately.

Acceptance criteria

• The conflict modal's buttons become [ Compare ] [ Overwrite ] [ Reload ] [< Cancel >], with Cancel still focused and Esc still cancelling.
• Compare closes the modal and opens the Compare to saved diff tab (CommandIds.CompareToSaved, cts) for that file, showing your buffer against what's on disk now. Nothing is written.
• After Compare, the diff tab is the active tab and has focus.
• Reload discards the buffer's edits and loads what's on disk — the same reload A clean tab shows what is actually on disk #269 does for a clean tab, so cursor line/column is kept and clamped, the gutter baseline resets, and undo history is cleared. ● and ⚠ both clear. Nothing is written.
• Reload does not ask a second time. You already chose it in a dialog; a confirm-the-confirm is noise.
• After a Reload, pressing Ctrl+S immediately is silent — the recorded state is the file that's now there.
• Overwrite and Cancel behave exactly as Save stops overwriting a file that changed underneath you #267 left them.
• The modal still fits an 80-column terminal with four buttons.

Implementation notes

• Close the modal, then open the diff tab — in that order. Removing a focused modal makes TG hand focus back into the editor group, and a Tabs switches Value to whichever tab takes focus, which isn't always the active one. Opening the tab first and closing after leaves the wrong tab selected. See AGENTS.md's note and OpenRevisionPicker (Compare to revision: run from a diff tab, the new diff opens behind the file tab #191).
• Reload should call A clean tab shows what is actually on disk #269's reload routine, not a second copy of it.
• The modal pops its KeybindingService off the IInputScopeStack on close, whichever button was pressed.

Tests

Compare writes nothing and leaves a diff tab active and focused; Reload writes nothing, replaces the buffer with the disk content, clears ● and ⚠, clears undo history, and makes the following save silent; Overwrite and Cancel are unchanged; the scope stack is balanced after each of the four buttons (nothing left pushed).

Out of scope

• Merging the two versions, or any three-way merge. Compare, overwrite or reload — the user resolves it.
• A "save as" / "keep both" escape, or writing the buffer to a backup file.
• Any change to the diff tab itself, or to cts.
• Changing what the modal says when the tab is clean (it doesn't appear — Save stops overwriting a file that changed underneath you #267).
• A conflict modal for a deleted file — the next slice, and a different shape.

[jamescrosswell]

Blocked by #269: The modal's Reload button calls 269's reload routine; building it first would mean writing that routine twice.

[jamescrosswell]

Draft PR #289 is up.

[jamescrosswell]

Seems to work quite well.

An issue I noticed while testing this:
If I have a directory open in TuiCode and files are created or removed from that directory by an external process, these files aren't added/removed from the Explorer automatically (and there's no way to manually refresh the Explorer).

Ideally the Explorer would automatically detect changes to the presence of files in any folders that are expanded in the tree.. Could you create that as a separate follow up issue as part of #133?

[jamescrosswell]

Thanks — glad it holds up.

Filed the Explorer refresh gap as #292, as a sub-issue of #133. I recorded your report as-is rather than shaping it; the Lead can pitch it. Worth noting it's a different gap from #268/#269/#271: those watch the files behind open tabs, so they recolour a row that already exists but never add or remove one.

#289 itself is green and unchanged by this.

[jamescrosswell]

Already answered above: #292 has it, as a sub-issue of #133. Replying only so this run marks your comment as read — no change to #289, which is still green.