[FEATURE]: upload attachments to the server so agent tools can read them (managed per-session store)

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

My partner uses the opencode web UI and attaches PDFs. The model can see them, but the agent's tools can't touch them — remote attachments arrive as data URIs, so there's no file on the server to read or convert. Replaying big base64 attachments also feeds the memory/db growth in #42263.

Proposal: add a streaming multipart upload route to the v2 session API. Store each file under <Global.Path.data>/attachments/<sessionID>/<attachmentID>/ and return an opaque managed URI. Clients put that URI in the existing PromptInput.FileAttachment; core validates session ownership and resolves it to an absolute path before provider-history lowering.

Limits and safety: stream to an exclusive temp file then rename atomically. 25 MiB/file, 100 MiB/session, 1 GiB global, typed 413 on overflow with partial cleanup. Filenames sanitized cross-platform, traversal and symlinks rejected, media types sniffed, unknown content stays path-only. No download route. Existing server auth policy applies. Unbound uploads deleted after 24h; bound files live with the session, cleanup to align with the shared disk-GC direction (#36093).

Model behavior: supported image/PDF gets native media on the first eligible turn with the path in filename (extends #41789). Everything else, and all replays, get one text part with the path — never both, and never persisted base64.

Plan: 3 PRs — (1) path-only backend flow + tests, (2) first-turn native media with path-only replay, (3) app/session-ui wiring. I have PR 1 implemented and tested, happy to open it once this design is ok'd.

Open questions: should this adopt the pending opaque managed-output URI format, or is opencode://attachment/<id> fine for now? Should the quotas join the planned shared disk-GC config?