feat(tui): ingest image attachments through Runtime Host

## Summary

Add a self-contained TUI image-attachment ingestion path that keeps a user-facing marker such as `[image 1]` while carrying the exact durable Session Artifact reference into model-facing message content.

This is split from #4079 / #4080 because the current TUI has no attachment ingestion or staging authority: its submit path carries text only, while Runtime Host accepts only canonical `session_file` attachments already committed to the Session ArtifactStore.

## Required flow

1. Accept an explicit image attachment action in TUI without blocking Send.
2. Ingest bytes through the existing Runtime Host `artifact.ingest` authority.
3. Keep image bytes and filesystem paths out of editor text; show an atomic marker such as `[image 1]`.
4. Submit the exact `AttachmentRef` alongside the visible label.
5. Preserve attachment identity through current-turn, steering, queued-successor, retry/retraction, and recovery paths.
6. Define deletion, failed-ingest, abandoned-draft, and orphan-artifact cleanup behavior.

## Acceptance criteria

- A TUI image marker serializes to the exact committed Session Artifact reference.
- Non-vision models receive the attachment name, MIME type, and Read reference without provider-native image bytes.
- Vision models retain the existing native-image path.
- Marker editing cannot silently bind a different image or leak a local path.
- Tests cover upload, marker-to-reference mapping, deletion, submission, queue/retraction, and recovery.
- Local and remote Runtime Host ownership boundaries remain explicit.

## Non-goals

- Do not create a second attachment store or Surface-owned durable authority.
- Do not infer OCR capability or automatically switch models.
- Do not expose temporary image paths in prompts or transcripts.

Refs #4079
Refs #4080

_AI assistance disclosure: Drafted and published with Codex at the author's direction._