fix: do not overwrite during merge

[valoq]

Fixes #1004

Conflicts were only resolved at the folder level. After accepting a merge, or when using --dir . or --here, each backend wrote files straight to disk and replaced same named files without asking.

Now they ask first. One shared helper in utils/fs.rs is called by tar, zip and 7z before writing a regular file, so all three behave the same: rename, overwrite or skip when prompted, overwrite with --yes, skip with --no, and no prompt when nothing clashes. Only existing files count as conflicts, so directories still merge and nothing is deleted.

Rar is left as is. Returning false from its Start callback cancels the whole extraction instead of skipping one file, and the per entry API would drop the large dictionary guard. I have not found a solution for it yet.

Added a test covering skip and overwrite for each archive format. Two old tests asserted the silent overwrite and now answer the prompt.

[valoq]

Rar is covered as well now

should be good for review

[marcospb19]

Hi, sorry for the big delay again, I should be revisiting and reviewing stuff soon.

[marcospb19]

Hey. This is addressing what I consider to be the most important problem at the moment.

I tried to solve this a couple months back but paused to prioritize the newer versions and landlock support.

---

One worry with this approach is, if the user chooses to rename a directory, all its children need their path to be renamed too, regardless of the children file type, so we need a path trie (data structure).

Please correct me if I'm wrong!! But below are my thoughts based on this fact.

And if we're achiving this level of control over decompression, then we need to put all path resolution behind this one magic (conflict resolution) struct that will handle it for all archives.

For this magic struct to control where things go, we need to check if all the libraries give us the control we need over decompression, I still haven't checked this thoughtfully.

However, a crazy simpler alternative to making this work for every archive code is to, again, have all decompression happen to a temporary directory folder, and then 1 generic code to move the results to the final directory doing all of this path-trie conflict resolution. There should be usability implications we must consider.

Any thoughts?