[BUG] Desktop app (Windows): delivered file cards open a claude.ai /api/.../files/{id}/contents URL in the browser — 404s or save-as with a corrupted filename

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

**Environment**
- OS: Windows 11 Pro (10.0.26200)
- App: Claude Code desktop app (Windows), local agent-mode session
- Files delivered by the agent via `SendUserFile` from a local git project directory (`.md` files, ~16 KB)

**Description**

Clicking a delivered file card in the conversation does not handle the file in-app. Instead it opens the file's API URL in the default browser:

```
https://claude.ai/api/organizations/{org_id}/files/{file_id}/contents
```

From there, two failure shapes observed across the last several clicks (multiple days):

1. **"File not found"** — the URL 404s and nothing is downloadable. Recurring over recent days.
2. **Browser save-as with a corrupted suggested filename** — two measured instances on 2026-08-19:
- ~08:28 PT: dashes stripped from the name — `paste-to-chat-capture-d1-stress-test-2026-08-19.md` was offered as `pastetochatcaptured1stresstest20260819.md`
- ~12:35 PT: filename reduced to a single character — the save dialog suggested `%` as the entire filename

When the download does succeed, the **content is intact** — both saved copies were SHA-256-verified byte-identical to the source files on disk. The corruption is in the delivery UX (redirect out of the app + filename loss), not the payload.

**Impact**

Filename corruption destroys at-a-glance file identity. With multiple similarly-captioned file cards in one conversation, this caused a wrong-file re-upload round trip to another Claude surface before the mix-up was caught. Current workaround: treat cards as decorative — the agent leads every delivery with the real host path, and copies files into `Downloads` under their correct names itself.

**Steps to reproduce**

1. In a local Claude Code desktop session on Windows, have the agent send a `.md` file via `SendUserFile` (attach).
2. Click the resulting file card in the conversation.
3. Observe: default browser opens the `/api/organizations/{org_id}/files/{file_id}/contents` URL; outcome is either a 404 ("file not found") or a save-as dialog with a corrupted suggested filename.

### What Should Happen?

Clicking the card should save/open the file in-app with its original filename — or, for files that already exist on the local host, offer "Show in Explorer" (as requested in #87649). At minimum, the browser redirect should carry a correct `Content-Disposition` filename.

**Related (same family, different variants):** #84550 (cards fail to deliver, macOS/Cowork), #86337 (Windows cards open instead of offering download), #86701 (Windows `.py` downloads fail), #87649 (no Show in Explorer / Copy path on Windows cards). This report adds the browser-redirect + filename-corruption variant on Windows.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

No source files or tests are named. Start by reproducing the Windows desktop flow through SendUserFile and inspect how the file card opens the /api/organizations/{org_id}/files/{file_id}/contents URL. Done means the delivered file remains accessible with its original filename, without the reported 404 or corrupted save-as name.

Vom Indexierungsmodell aus dem Issue-Text verfasst.