fix(app): decode dropped file URLs

[fancive]

Issue for this PR

Closes #42747

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Desktop OS file drops provide canonical file:// URLs. The prompt drop handler previously removed only the file: prefix, leaving percent escapes and extra leading slashes in the attachment path. Files with reserved characters such as ? then reached the Read tool as %3F paths and could not be found.

This change parses file:// drops into decoded native paths while retaining the canonical URL for the request. It preserves the existing file:relative/path behavior used by sidebar file-tree drags and covers POSIX paths, Windows drives, UNC hosts, localhost, and unsupported URL inputs.

How did you verify your code works?

• Focused drop-to-request tests: 69 passed
• Browser tests: 41 passed
• bun typecheck in packages/app
• bun run build in packages/app
• Monorepo pre-push typecheck: 30/30 tasks
• no-mistakes review, test, document, and lint gates passed

Screenshots / recordings

Not applicable. This fixes file-path translation at the drag-and-drop request boundary.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[Enough1122]

AI code review — automated review for reference; please use your judgment.

1. packages/app/src/components/prompt-input/attachments.ts:41 — Single-slash file:/abs/path URLs (valid per RFC 8089-style producers) miss the file:// branch and fall into the raw-string path, keeping %XX escapes literally in the file path. Why it matters: the very bug this PR fixes (%-encoded names) resurfaces for that URL spelling. Suggestion: route anything matching /^file:\/\// or /^file:\/[^\/]/… more simply: attempt parseFileURL whenever the string starts with file: and only fall back to the opaque-path branch when parsing fails.

2. packages/app/src/context/file/path.ts:84 — If decodeFilePath throws on malformed percent-sequences ("%E0%A4", "%zz"), a malformed drop payload will throw inside the drop handler instead of being ignored. Why it matters: one bad drag source would break the whole attachment flow with an unhandled exception. Suggestion: guarantee a safe fallback (try/catch returning the raw pathname), and add a test for parseFileURL("file:///tmp/%zz.png").

3. packages/app/src/components/prompt-input/attachments.ts:39 (nit) — Scheme check is case-sensitive, so FILE://host/p payloads are rejected outright even though new URL() normalizes schemes to lowercase. Cheap fix: compare against input.toLowerCase().startsWith("file:").

4. packages/app/src/context/file/path.test.ts:60 — Coverage is strong (reserved chars, drive letters, UNC, localhost, canParse fallback). Consider adding the two gap cases from items 1–2 (single-slash URL, malformed escape) so the supported-input contract stays pinned.

— automated review (ox-alpha, round2)