Drag-and-drop file transfer has no progress feedback

Start with the existing backend transfer operation that drag-and-drop calls, then trace how the file preview widgets receive its results; the issue names no specific files. Before writing code, check CONTRIBUTING.md, which asks for larger changes to be discussed on Discord, and align on the per-file state model with #929, #1685 and #2044. Done means per-file queued, in-progress, completed and failed states are visible in the widgets for transfers from inside and outside Wave.

Drag-and-drop file transfer has no progress feedback

Summary

Dragging files between widgets (local preview → remote preview, remote → local, or between
directories) works, but it is completely silent while it happens. There is no progress
indicator, no percentage, no byte counter, no completion notification, and nothing in the UI
that tells me a transfer is still running versus already finished versus never started at all.

The practical effect is that I cannot tell a working transfer from a failed one. If I drop a
large file and the UI gives me no feedback, I have no way to know whether to wait, retry, or
go check with ls. So the most reliable workflow ends up being "drop it, then switch to a
terminal and verify" — which defeats the point of dragging in the first place.

Wave Version

0.14.5

OS

macOS 26.2 (arm64)

Steps to reproduce

1. Open a local preview widget and a remote preview widget (e.g. via an SSH connection) side
   by side.
2. Drag one or more files from the local preview into the remote preview directory.
3. Observe: the drop completes, and eventually the file appears in the destination listing.
   During the transfer there is no progress indicator, percentage, throughput, or ETA —
   nothing at all.
4. Drag a large file (hundreds of MB, or a big video/archive) and repeat step 3. The wait can
   be long enough that it is indistinguishable from the drag having been ignored.
5. Try the same drag over a connection with poor bandwidth. There is still no feedback, and no
   error or failure indication if the transfer does not complete.

Expected behavior

Some visible indication that a transfer is in flight and how far along it is. Concretely,
what I would hope for:

• A progress indicator on the source and/or destination widget while the transfer runs —
  percentage, or bytes transferred / total bytes, plus throughput and ETA for large files
• A visible drop-target highlight while dragging over a widget, so it is clear the widget will
  accept the drop at all (right now there is no hover affordance)
• A clear completion state, and an explicit failure state if the transfer errors out
• Transfers tracked per file, so dropping 10 files shows 10 distinguishable items rather than
  one ambiguous blob
• Ideally the transfer should be non-blocking — I would want to keep working in other widgets
  while it runs, and come back to a finished (or failed) result

The reference point here is Xftp / any SFTP client: transfer list with live progress, and
background transfers that survive navigating away.

Actual behavior

The transfer runs with no feedback of any kind. Based on the docs and my own testing, the
file-view keybindings and drag-and-drop documentation describe the drag gesture itself but say
nothing about progress reporting, and I could not find a progress indicator anywhere in the UI.

Worth separating clearly: this is not a request to add drag-and-drop. That capability
already exists and works. #929 asks for dragging between directory preview blocks, #1685 asks
for Xftp-style drag-and-drop transfer, and #2044 asks for multi-select during upload. This
issue is only about the missing feedback on transfers that already run — it applies
equally to transfers that originate outside Wave (e.g. dragging in from Finder/Explorer), so it
is broader than just the widget-to-widget case.

Current workarounds

• Switch to a terminal block and verify with ls -lh, du -sh, or df -h.
• Use rsync/scp/cp in a terminal, where at least the shell reports progress, then refresh
  the preview with Alt+Shift+R.

Both work, but they mean the GUI drag gesture can never be trusted on its own.

Anything else?

My guess at the shape of the work: the transfer already exists as a backend operation, so this
is mostly a matter of surfacing per-file state (queued / in-progress / done / failed) into the
existing model and rendering it in the file widgets. That also seems like it would naturally
serve #929 and #1685, since a real transfer list is what makes those usable as an SFTP client.

Per CONTRIBUTING.md I understand larger changes should be discussed in Discord first — happy to
move this there if that is the better venue. I am also happy to dig into the code and propose a
concrete approach, either as an issue comment or a PR, if that would help.