fix(server,web): bound image prompts, name provider on consent, render generated images

[leoisadev1]

What Changed

Bounds image-tool content before it reaches sinks outside the caller's chat transcript, names the provider on the consent card, and fixes generated images not rendering on web.

• GenerateImage tool events and persisted activities no longer carry prompt or inputImages. boundedImageToolArgs strips them from item.started args, request.opened args, and persisted approval.requested activities (routing fields like operation, provider, allowProvider, count, quality, aspectRatio stay). The event store stays clean, which covers analytics and logs; observational memory (processOutputResult and the rollback restore) scrubs tool-invocation parts via boundedImageToolMessage.
• Crossing providers during an edit used to depend on the model retrying with allowProvider after needs-consent, with nothing recording the user's agreement. The retried call now opens the existing one-shot approval card with a provider-aware detail — "Send the chat images to Grok?" — so the persisted request.resolved (actor: "user") records real consent, and the approval.requested activity keeps the bounded args so the record stays machine-readable.
• Web render fix: AssistantMessageRow never mounted BotMessageAttachments and visibleBotChatMessages kept only the last settled assistant record per turn, so a generated image posted mid-turn never rendered on web/desktop. Attachment posts now stay visible next to the final reply, and the row renders them like mobile already does.
• Tests: sink coverage for tool events, approval activities, observational memory, and entity memory (asserts no writes); consent-card detail and bounded persisted args; a server-side test that renders a finished image in a group chat; visibleBotChatMessages coverage for attachment posts.

Refs #450. The one item not covered here is a real generation through each supported subscription path (ChatGPT and Grok) — it needs live provider credentials, which this environment doesn't have; the fake-adapter tests cover both routing paths.

Why

The remaining #450 acceptance items: keep prompts/images out of analytics, memory, logs, and feedback; record user confirmation before crossing providers on edit; and render a finished image in a group chat. Verification surfaced the web render gap — the feature was invisible on the main client, so fixing it is part of exposing image generation.

UI Changes

Before — assistant message rendered text only; the image attachment never appeared:

After — the image paints inline under the assistant reply, and the consent card names the provider:

Checklist

• This PR is small and focused
• I explained what changed and why
• I linked the accepted plugin or provider proposal in Why, or this PR does not add one
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Link to Devin session: https://app.devin.ai/sessions/462eb37e238e43b69e896a94c638a5a9
Open in Devin Desktop: https://app.devin.ai/desktop/session/462eb37e238e43b69e896a94c638a5a9?variant=devin
Requested by: @leoisadev1

---

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
akeru-bot-landing	Ignored		Oct 6, 2026 5:51pm UTC

[devin-ai-integration]

Devin Review found 2 potential issues.

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Image generation prompts and consent flow changes.

The changes since the last review appear safe to merge.

Summary

This PR keeps image prompts and input-image references out of tool events and saved memory, names the provider on approval cards, and shows generated attachments in chat.

• Since the last review, only BotThreadLanding.markdown.test.ts changed. Its checks now match the code that shows turn details once.
• No new actionable issues were found.
• Both earlier Greptile threads were manually resolved without explanatory replies. Neither supplied a comment number.

_{Reviews (3) · Last reviewed commit: "test(web): assert step meters land on th..."}

[devin-ai-integration]

Fixed in d355d3c. imageRoutePlan honors an explicit provider as the pin (consented order only reorders within candidates), so the card now names provider ?? allowProvider. Added toolContent.test.ts covering both the consent retry and the mismatch case.

[devin-ai-integration]

Fixed in d355d3c — same root cause as the Devin Review thread: the card now names provider ?? allowProvider, matching imageRoutePlan's pin. On the fallback half of the finding: a consented provider failing and falling back to the originally intended provider is the defined fallback path — the intended provider was never consent-gated since the images were addressed to it from the start. Only the naming mismatch was a real bug.

[devin-ai-integration]

Fixed in d355d3c. New lastAssistantMessageIdByTurn helper in botConversationPresentation.ts picks the one assistant row per turn that carries shared details; stepMeter and pluginResults are gated on it in both BotThreadLanding and GroupThreadLanding. Behavior test added in ThreadLanding.delegations.test.tsx ("renders turn details once, on the last assistant row of the turn").

[devin-ai-integration]

Covered on two levels in d355d3c and the earlier web commit: visibleBotChatMessages has unit tests proving attachment posts stay visible next to the final answer, and ThreadLanding.delegations.test.tsx now renders BotThreadLanding and asserts the attachment row + final row both mount AssistantMessageRow (attachments render inside it since 10a90a2). Verified end to end with a seeded fixture — the generated JPEG paints inline under the assistant reply (screenshots in the PR body). A live provider e2e is out of scope for CI (no real subscriptions).