fix regression from #2620: warn without blocking paste

[valoq]

This reverts #2620 and instead of breaking the paste function, it only prints a warning and keeps things simple

[CatsDeservePets]

To be honest, there are some things I don't.
I think I mentioned it before, but the new line handling is all over the place throughout the program. Copying and cutting shows error messages, tagging or the clipboard only show error messages inside the logs. This is confusing and not intuitive in my opinion.

Maybe we can centralise this a litte bit more.

Another thing are error and log messages. They all slightly differ in their wording and some quote the path in question while others don't (this is a general problem with lf, I think I should work on #2213 again).

2026/06/30 02:25:37 tags: skipping tag with newline in path: "/Users/user/.local/share/lf/Icon\r"

2026/06/30 02:24:15 clipboard: skipping path with newline: "/Users/user/.local/share/lf/Icon\r"

2026/06/30 02:24:15 error: copy: cannot copy /Users/user/.local/share/lf/Icon because the name contains a newline

Before merging this PR, I'd like to hear what @joelim-work has to say about this whole topic in general.

[valoq]

I absolutely agree and I keep thinking about the entire newline issue far more then probably reasonable for this edge case. The real solution I would like to work on is to treat all newlines in filenames as invalid, which is actually a new POSIX recommendation as well https://lore.kernel.org/all/iezzxq25mqdcapusb32euu3fgvz7djtrn5n66emb72jb3bqltx@lr2545vnc55k/
Full Spec: https://ieeexplore.ieee.org/document/10555529

Lf should probably just continue to display the new line with the current substitute to indicate the problematic filename, but refuse any operations on it.

But this is all something for after the next release, and this PR was just meant to get a somewhat "clean" warning into the current version without introducing real changes this late before the hopefully soon r42