fix(ui): prevent MCP app iframe from staying stuck at compressed width

[clayarnoldg2m]

Summary

• Fixes Resize goose desktop shrink the mcp app and it never grows back. #6818 — MCP app iframe gets stuck at compressed width after window resize
• The size-changed notification from MCP apps was setting a fixed pixel width on the container, which never grew back when the window expanded (the app can't detect size changes beyond its own container bounds)
• Changed to use the app-reported width as maxWidth instead of width, so the container stays fluid (width: 100%) and naturally expands with the window while still respecting the app's preferred maximum

Root cause

PR #6376 introduced width tracking from ui/notifications/size-changed. When an app reported its width (e.g., 400px when compressed), the container was pinned to that exact width. Since the app is inside the container, it couldn't detect the window growing beyond 400px to send a larger width notification — a feedback loop that kept it stuck.

Test plan

• Open an MCP app in Goose desktop
• Shrink the window to compress the app
• Expand the window back — app should now fill available width (previously stayed compressed)
• Verify apps that report a preferred width still get maxWidth capping
• npx tsc --noEmit passes
• cargo clippy clean

🤖 Generated with Claude Code

[DOsinga]

I'm not seeing this issue on main with my toy MCP app, it just always the width of the screen. thoughts @aharvard ?

[aharvard]

@DOsinga it depends on how the app is sending width data in the size change message. Regardless, what we have for goose right now is incorrect. Will share notes!

[aharvard]

Thanks for looking into this @clayarnoldg2m, but I don't think this is the right fix. The underlying issue is that PR #6376 should be reverted entirely.

Why this PR doesn't solve the problem

Swapping width → maxWidth still lets the app drive the container width. If an app reports width: 400 when compressed, the container gets maxWidth: 400px — which caps it at that size even when the chat window is wider. The feedback loop is still there, just inverted.

The actual problem with #6376

For the inline chat view, the host owns the width and the app owns the height. The app should always render at width: 100% and adapt responsively. The width value in ui/notifications/size-changed should be ignored in this display mode.

This was the consensus from the upstream spec discussion in modelcontextprotocol/ext-apps#153. The spec defines containerDimensions to communicate the sizing model to apps — for inline mode that means something like { width: <fixed> } (host controls) with flexible height (app controls). The original proposal to rename size-changed to height-changed was only dropped to stay extensible for other display modes (sidebar, popup) — not because inline apps should control their width.

What we should do instead

1. Revert #6376 — remove iframeWidth state and always use width: 100% for inline mode
2. Properly send containerDimensions in the host context so apps know the sizing model (there's already a TODO for this in the code... coming soon!)

See also: owtaylor's analysis on #6818