fix(file-operations): make the conflict dialog X button cancel #391

Split from the grouped rename and copy/paste report (#354, item 4 of 5).

Strata version

Reproduced on source build of Strata v0.10.0 (main, debug build) with an isolated temp HOME / XDG fixture.

What happened?

When a paste collides with an existing name, Strata shows a “File already exists” dialog with Replace, Skip, Cancel, and an X close button in the header. Clicking X does nothing: the dialog stays open and no choice is applied.

Cancel and Escape already dismiss the dialog. The header close control looks like the same action and should behave the same way.

Steps to reproduce

1. Create source/report.txt and dest/report.txt (same basename, different content).
2. Copy source/report.txt and paste into dest/ so the “File already exists” dialog appears.
3. Click the header X close button.
4. Observe that the dialog does not dismiss and the paste is neither cancelled nor completed.
5. Confirm that Cancel and Escape do dismiss the dialog without writing files.

Expected behavior

X, Cancel, and Escape all cancel the conflict flow:

• The dialog is dismissed.
• No files are overwritten, renamed, or created as a result of that paste.
• Cancelling abandons the whole operation (matching current Cancel behavior).
• Focus returns to the browser so keyboard use can continue.

Replace and Skip must keep their current meaning.

Screenshots or video

Repro recording (X fails to dismiss; Escape / Cancel work; files unchanged):

https://cursor.com/artifacts/v/art-9612e792-e219-46e3-bfd8-53dd93ff8dc2

Additional context

confirm_replace_conflict in src/ui/browser.rs builds the dialog with message_dialog_layout, which always includes layout.close (the header X). Handlers are wired for Cancel, Skip, Replace, and Escape, but layout.close is never connected. Other modals in the same file (transfer-destination, empty-trash, archive-conflict) already connect layout.close to dismiss_modal_layer.

Copy/move undo collision uses the same confirm_replace_conflict, so X is broken there too. Fix the shared helper rather than only the paste caller.

Acceptance criteria

• The conflict dialog’s X, Cancel, and Escape all dismiss the dialog without modifying files.
• That cancel path is used for paste collisions and for undo-move collisions.
• Multi-conflict prompts: X on any prompt abandons the whole operation, including earlier Replace/Skip choices from that batch.
• Replace, Skip, Enter, and “apply to all” are unchanged.
• After dismiss, focus returns to the browser.
• Automated tests (or a focused UI test) assert that close, cancel, and escape take the same cancel path.

Labels suggestion: bug, UX