web: surface ui/message and app logging in panels below the running app

[cliffhall]

Summary

Surface two message streams from a running MCP App below the widget on the Apps screen:

• ui/message — user messages submitted by the view are displayed in a "Messages" panel (data-testid="apps-messages"). The inspector has no conversation to continue, so display-only is the correct host behavior.
• notifications/message (logging) — the already-advertised logging capability finally goes somewhere: a collapsible "App logs" panel (data-testid="apps-logs", default-expanded) with severity badges and logger names.

Why

Both channels are advertised host capabilities today, and both are silently dropped — a widget developer can't tell whether their ui/message/log calls work.

Reference implementation (PR #1510)

Re-implement informed by these changes at 33fac3f:

• clients/web/src/components/elements/AppRenderer/AppRenderer.tsx — onMessage/onLog props, onmessage bridge handler, loggingmessage listener
• clients/web/src/components/screens/AppsScreen/AppsScreen.tsx — messages/appLogs state, PinnedPanel/MessageLogStack/AppLogRow subcomponents; reuses existing LogLevelBadge and ContentViewer elements

Depends on

• CSP enforcement + resource-error surfacing in the bridge factory (same files; land first). Independent of the hostContext/size-changed issues but shares AppsScreen — keep the lane sequential.

Notes

• Reuse LogLevelBadge/ContentViewer; don't grow new level-badge logic.
• Mantine rules apply to the new panels: .withProps() constants, theme variants, no inline styles, tokens only.
• The mcp_app_demo preset exercises both channels.
• Coverage gate ≥90 on all four dimensions.

Part of the PR #1510 decomposition (see tracking issue).