Image upload fails with EXDEV (cross-device rename) when user profile AppData is redirected to another volume (Windows)

### Environment
- OS: Windows 11 Home, 10.0.26200
- Claude Desktop, reinstalled recently from the official website installer
- User profile's `AppData\Roaming` is redirected via a reparse point to a `WpSystem\\...` folder. In my case the reparse target string resolves to `C:\WpSystem\...`, but that path doesn't exist under normal access — the real data lives at `D:\WpSystem\\...` on a different drive letter. `stat -f` on both paths returns the same filesystem ID, so it's the same underlying volume, just reachable through two different drive-letter mount points.

### Steps to reproduce
1. Have a Windows profile where AppData is redirected this way (common with storage migration tools / enterprise imaging / "move new content to another drive" configs).
2. Open Claude Desktop, start a chat.
3. Paste or attach an image.

### Actual behavior
The image upload consistently fails with:
```
EXDEV: cross-device link not permitted, rename 'D:\WpSystem\S-1-5-21-...\...\pending-uploads\-_image.png' -> 'C:\Users\\AppData\Roaming\Claude\local-agent-mode-sessions\\...\uploads\-_image.png'
```
The failed file is left behind in `pending-uploads` every time, so they accumulate with every failed attempt.

Separately (possibly related), after not opening the app for about a month due to a lapsed subscription, the app failed to start entirely with:
```
Failed to start Claude's workspace
failed to set session disk path: session disk not found: ...\vm_bundles\claudevm.bundle\sessiondata.vhdx
```
Reinstalling the app fixed the startup issue, but the image-upload EXDEV error persists after reinstall (as expected, since it's rooted in the OS-level profile redirection, not the app installation).

### Suspected root cause
The app's config (`config.json`) contains a `lastSeenRequireCoworkFullVmSandbox` key, suggesting file operations for uploads may go through a VM/sandbox layer ("Cowork Full VM Sandbox"). It looks like the code path handling the upload does a plain rename/move from the pending-uploads temp location to the final destination, and does not fall back to copy+delete when the OS (or the sandbox's virtualized mount) reports the source and destination as different devices — which happens when the user's profile folders are split across drive letters/volumes this way.

### Suggested fix
When moving uploaded files, catch `EXDEV` and fall back to copy-then-delete instead of surfacing the raw error to the user.

### Impact
Every image paste/attach fails 100% of the time on this setup, with no workaround inside the app itself.

Start by reproducing the upload from pending-uploads on a Windows profile whose AppData is redirected across drive-letter mount points. Locate the upload move that targets local-agent-mode-sessions and inspect config.json for the related sandbox path; done means image uploads succeed without EXDEV and failed temporary files do not accumulate.

Written by the indexing model from the issue text.