Forward target app XMLUI Inspector traces into Bram log

[judell]

Problem

Bram currently forwards XMLUI Inspector trace entries from the tools/agent XMLUI iframe into bram-trace.log, but the target app iframe does not appear to feed its XMLUI engine trace stream into the shell log.

The two iframes share the Bram shell as parent, but they are separate XMLUI apps:

• The tools iframe loads /__shell/helpers.js before XMLUI boots. That helper defines logToHost / iframeTrace and includes the Inspector tap that polls window._xsLogs and logs entries as [iframe] subkind=inspector-event.
• The target app iframe loads its own app assets and does not automatically get Bram's helper layer. In the voice app, for example, the local Inspector can see window._xsLogs, but those entries are not forwarded to bram-trace.log.
• The parent shell currently accepts right-pane postMessage traffic for the voice control protocol (voice-start / voice-stop), but not a generic target-app trace stream.

Desired behavior

When enabled, XMLUI Inspector entries from the target app should be forwarded into Bram's trace log and interleaved with the shell/tools events, with enough metadata to identify the source iframe/app.

Example log shape:

{
  "kind": "iframe-trace",
  "source": "target-app",
  "subkind": "inspector-event",
  "entry": { "kind": "handler:start", "...": "..." }
}

This should make the Inspector trace tab/log useful for diagnosing interactions that cross the tools iframe, shell, and target app iframe.

Proposed design

Add a small target-safe bridge rather than loading the full /__shell/helpers.js into target apps.

Parent side:

• Extend the shell's right-pane message listener to accept a trace message shape, for example:

{
  type: "right-pane",
  kind: "iframe-trace",
  subkind: "inspector-event",
  entry: ...
}

• Verify ev.source is the current target/right-pane iframe before accepting it.
• Cap payload size and per-tick volume.
• Tag records as source: "target-app" or equivalent before routing through log_from_right_pane.
• Gate this behind the same trace/Inspector setting used for the tools-side Inspector tap, or a neighboring setting if target tracing should be independently controlled.

Target side:

• Provide a tiny bridge script, for example /__shell/target-inspector-bridge.js, that can be loaded before XMLUI.
• The bridge polls window._xsLogs at the same cadence as the existing tools Inspector tap and posts new entries to window.parent.
• It should expose only the minimal target-facing logging surface, not the full agent-pane helper API.

Notes

This came up while testing the voice target app with an embedded XMLUI Inspector. The Inspector export confirmed rich XMLUI engine traces for the Bram tools app, but not that the target app's local _xsLogs stream is being forwarded into the rolling Bram log.

Relevant current implementation points:

• app/tools/index.html loads /__shell/helpers.js before XMLUI so tools markup can use shell helpers and logging.
• app/__shell/helpers.js contains the existing Inspector tap that polls window._xsLogs and emits subkind=inspector-event.
• app/main.js already has a right-pane postMessage handler for target-driven voice start/stop, which is likely the right place to accept validated target trace messages.