feat: preview image attachments in chat

[richardfogaca]

Linked issue

Fixes #1975

Summary

• Add authenticated PNG, JPEG, GIF, and WebP thumbnails to sent and reloaded web transcripts.
• Allow users to click thumbnails for the full image preview.
• Suppress matching image attachment boilerplate only in the rendered message body.

Why / context

Uploads currently display only filesystem paths in chat. Image previews make uploaded images convenient to inspect without weakening authorization or changing the agent-visible prompt text.

Implementation notes

• Sign upload associations and persist trusted attachment metadata on the corresponding task.
• Serve bytes through an authenticated, session/task-scoped route with MIME validation and realpath containment checks.
• Manage browser blob URLs across loading, failure, decode error, and unmount states, with a compact fallback when an image is unavailable.
• Suppress matching attachment boilerplate at render time only, failing closed when duplicate basenames make a match ambiguous.

Screenshots

Validation / test plan

• Daemon focused tests: 20 passed
• UI focused tests: 11 passed
• Follow-up focused UI tests: 7 passed
• Core API tests: 68 passed
• Daemon, UI, core, and client source-condition typechecks passed
• Formatting and diff checks passed
• Independent review completed with 0 blockers
• Authenticated browser QA passed send, click preview, reload persistence, body suppression, and bearer-authenticated 200 retrieval

Screenshots / demos

Manual browser verification completed; no durable screenshot artifact is attached.

Risks / rollout / rollback

The filesystem and authorization surface is protected by bearer authentication, session/task association, and upload-root containment. Roll back by reverting this commit.

Out of scope / follow-ups

• Non-image previews
• Gateway rendering
• Model vision
• Migrations or backfills
• Nonblocking follow-up: centralize attachment boilerplate formatter/parser ownership

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[mistercrunch]

One potential concern around this is the fact that we might be trying to decouple the daemon with the filesystem. Here this assumes the daemon has access to user's home (as the current destination upload target).

Not sure what exactly it means:

• potentially moving the upload destination elsewhere where daemon can see (?) duplicating files between user home and a daemon-visible place?
• merge this and sort-out later when we approach the de-coupling as something more holistic? For the record, we have the filename autocomplete in conversations and the "file browser" tab in BranchModal