## Summary

On Windows, `trash::delete_with_info` can return an error even when the
file was successfully moved to the Recycle Bin.

This is caused by a race condition in the `trash` crate: after
`IFileOperation::PerformOperations` completes, it re-binds the trashed
item via `SHCreateItemFromParsingName` to read its metadata, but the
shell's virtual namespace cache may not yet reflect the new item,
producing an error. Previously, the delete loop propagated this error
and aborted the entire batch. The outer `detach_and_log_err` swallowed
the error, so the user received no feedback.

This PR handles each entry independently: entries that fail to delete
are skipped, the loop continues, and undo history is recorded for the
entries that succeeded.

The upstream root cause (the post-operation re-bind race in
`zed-industries/trash-rs`) will be addressed separately.

Before:


https://github.com/user-attachments/assets/59a95ac5-098b-42dc-bffb-f3240c6b966d

After:


https://github.com/user-attachments/assets/0cd6c0b3-2ee3-4bf2-a243-3e8a83d05dd7



## Test plan

- [ ] Select multiple files in the project panel on Windows
- [ ] Trash them (right-click > Move to Trash, or `Delete` key)
- [ ] Confirm all selected files are deleted, even if one triggers the
trash-crate race
- [ ] Undo restores the files that were successfully trashed

Release Notes:

- Improved handling of failed trash or delete operations in the Project
Panel in order to display a toast informing the user that some files
could not be trashed or deleted

---------

Co-authored-by: dino <dinojoaocosta@gmail.com>