feat(agent): multimodal prompt — native image/audio content blocks gated by promptCapabilities

[kaizhou-lab]

Summary

Attachments that the target agent can natively consume (per its declared promptCapabilities) are now delivered as protocol image/audio content blocks instead of file-path text. Agents without the capability keep the exact pre-existing path-based wire form, byte for byte. Frontend half: iOfficeAI/AionUi#3849.

How it works

• Dispatch-time partition (aionui-ai-agent/src/media.rs): the only layer that knows the agent's capabilities splits SendMessageData.files into native-block media vs path files, stripping/rebuilding the [[AION_FILES]] block with the same validate-then-rebuild approach as the aionrs precedent (manager/aionrs/content.rs). Persisted/broadcast message content is untouched — UI chips and history render exactly as before. Degradation to path form: capability absent, non-media mime, SVG, unreadable, or >5MB (warn-logged).
• Capability surface: new IAgentTask::prompt_media_caps() (default none) — AcpAgentManager reads the initialize response's promptCapabilities; SessionAgentTask reads the backend's prompt_blocks.
• ACP path (agent_session_flow): session/prompt becomes a text block plus one base64 ImageContent/AudioContent per capable attachment (uri: file://…). Any read failure degrades the whole prompt back to the plain text form. Transport is LinesCodec::new() (unbounded) on both sides.
• Session path (session_agent): capable media rides as seam ContentBlock::Image/Audio; the claude/codex adapters' existing base64 encoders consume them unchanged.
• Capability pipeline to the frontend: ACP agents already persist prompt_capabilities inside agent_metadata.agent_capabilities (003 seeds + live handshake refresh). Migration 037 json_patches the same key onto the direct-CLI rows (claude/codex: image only), mirroring 036's fork pattern. The conversation detail response gains a prompt_capability {image, audio} projection next to fork_capability (one metadata load feeds both; lists stay N+1-free).

Live verification

• claude 2.1.221 (--input-format stream-json): a generated 24px red-square-on-blue PNG sent as the adapter's source-wrapped base64 image block → "图中是蓝色背景上的一个红色正方形。"
• codebuddy --acp: session/prompt with {type:"image", data, mimeType, uri} → "A red square centered on a blue background." (stopReason: end_turn, no error with the uri field present)

Testing (targeted; CI runs the full workspace suite)

• aionui-ai-agent: media partition (6), ACP prompt blocks (3), session send partition (1) — all pass
• aionui-conversation: lib 376 + conversation_extended 38 (incl. new get_projects_prompt_capability_on_detail_path) — all pass
• aionui-db: 330 pass with migration 037
• cargo fmt --check clean; targeted clippy (-p ai-agent/conversation/api-types) clean

[kaizhou-lab]

Local e2e — real UI wire shapes, full upload chain

Ran a local instance (aioncore --local) and replayed the exact requests the renderer makes:

1. POST /api/conversations with the guid-page body (assistant.id only, no type/agent_id) → claude conversation created; GET /api/conversations/{id} projects prompt_capability: {"image": true, "audio": false} (migration 037 + detail post-fill).
2. POST /api/fs/upload (multipart file + conversation_id, same as FileService.uploadFileViaHttp) → <tmp>/aionui/<conv>/probe-red-square.png.
3. POST /api/conversations/{id}/messages with files: [{"kind":"upload","path":...}] (same as collectChatFileRefs).

Result:

• Server log (info level): session prompt carries native media content blocks conversation_id=609a4c0e images=1 audios=0 — the attachment took the native-block path, not the path-text fallback.
• claude's reply: "图中是一个蓝色背景上居中的红色正方形(实心方块)。" — exact pixel content of the generated probe PNG, with the prompt forbidding tool use, so the pixels came through the base64 vision block.

The last commit adds that info line on both dispatch paths (ACP + session) so native-block delivery is diagnosable in production logs.