feat(web): add bounded file and image attachments with safe rendering

[sowen1023]

Parent

• [Roadmap] OpenPI Web：像 Codex / Kimi Code 一样的本地浏览器 Agent 工作台 #76

Problem

The Web composer currently accepts only a string prompt. It has no file picker, paste/drop attachment flow, image preview, or multimodal prompt projection. Model output also lacks a reviewed browser policy for rendering image content, so remote image references remain inert.

This prevents common coding workflows such as attaching a screenshot, a log, or a small reference file while preserving the original evidence identity.

Value

• Support screenshot-driven debugging and multimodal models.
• Let users attach bounded evidence without copying large content into the text box.
• Make input provenance, model compatibility, and cleanup explicit.

Approach constraints

• Reuse Pi message/content-block semantics and provider capability checks.
• Bind uploaded content to the expected workspace, Session, and prompt command.
• Enforce explicit count, per-file, aggregate-byte, MIME, and filename bounds before admission.
• Do not turn a browser-supplied path into unrestricted filesystem authority.
• Keep canonical bytes separate from bounded model/UI projections and report truncation honestly.
• Clean temporary artifacts on rejection, cancellation, settlement, and host shutdown.
• Render untrusted SVG/HTML and remote resources under a reviewed browser security policy.

Acceptance criteria

• Users can select, paste, or drop supported files and images into the composer.
• The UI shows name, type, size, removal state, and admission errors before sending.
• Unsupported models/providers fail clearly without silently dropping attachments.
• Prompt admission is atomic: text and all accepted attachments target the same expected Session.
• Count, MIME, filename, per-file, and aggregate size limits are tested.
• Traversal, symlink, stale-session, cancellation, and cleanup cases fail closed.
• Supported image output is rendered safely; unsupported content has a usable download/link fallback.
• Refresh/reconnect does not duplicate an admitted attachment.
• Protocol, host, runtime, UI, and real-browser tests cover the flow.
• bun run check and bun run test pass.

Out of scope

• Cloud attachment storage.
• Arbitrary large-file transfer.
• Fetching remote URLs on behalf of the user without a separate permission design.

[testikun]

I am taking a focused host-owned attachment staging lifecycle slice. This PR will add private Web-host temporary storage with server-generated identities, exact workspace/Session/command binding, atomic single-consume receipts, explicit count/byte defense-in-depth bounds, traversal/symlink rejection, and deterministic cleanup on rejection, cancellation, settlement, and host disposal. This is intentionally distinct from #365/#380 metadata admission validation and #384 composer/UI work; it will not add browser UI or model projection. No UI changes are planned, so a real-browser screenshot is not applicable to this slice.