Failed transfer events drop the file plan and progress context

[vsamarth]

Severity

Low

Problem

When transfers fail after an offer or progress has already established useful context, app failure events discard that context. Receiver failures are mapped through failed_offer_event, which resets item count, total size, bytes received, plan, snapshot, connection path, and files. Sender failures through failed_event_from_error similarly reset counts and plan information.

This makes failures harder to understand in the UI or CLI because the user loses the file list and partial progress at the moment they need it most.

How to reproduce

1. Start a multi-file or large-file transfer.
2. Let the receiver accept and begin receiving progress.
3. Interrupt the transfer, for example by closing one side or simulating a network failure.
4. Observe the final failed event.
5. The final event can report zero items, zero bytes, plan: None, and snapshot: None even though the app previously knew the plan and partial progress.

A focused test can feed a progress event followed by a core failure and assert that the final app event preserves the last known plan/snapshot/bytes.

Expected behavior

Failure events should carry the last known transfer plan and progress snapshot whenever available. The UI can then show which transfer failed, how far it got, and which files were involved.

Relevant code

• crates/app/src/receiver/session.rs: failed_offer_event
• crates/app/src/send/session.rs: failed_event_from_error, map_sender_event

Notes

This is lower severity because it does not appear to corrupt data, but it will make debugging and user support harder.