PostMessageTransport: make debug logging opt-in (or accept a logger)

[AlmogBaku]

Problem

PostMessageTransport calls console.debug unconditionally (src/message-transport.ts at 264d9ca, lines 77, 82, 87 and 128):

• "Sending message" for every outgoing message except tool-input-partial
• "Parsed message" for every valid incoming message
• "Ignoring message from unknown source" for every message from another frame

A host cannot turn these off. The transport takes no option for it, and the only workaround is wrapping console.debug globally.

The noise grows with the number of Apps on a page. Each card's host transport listens on the same window, so a message from any View reaches every bridge. The owning bridge logs "Parsed message", and each of the other N−1 bridges logs "Ignoring message from unknown source" with the full MessageEvent. With four cards in a conversation, every View message produces four host lines, plus the View's own "Sending message" inside its frame. Size changes and host-context updates fan out the same way.

The source check is correct. Only the logging is the problem.

Prior discussion

• PostMessageTransport logs noisy console.error for expected unknown sources during development #237 / fix: change unknown source message log from error to debug level #239 moved the unknown-source log from console.error to console.debug.
• fix: skip debug log for high-frequency tool-input-partial notifications #546 skipped the log for tool-input-partial because it flooded the console.
• PostMessageTransport logs complete JSON-RPC payloads, including tool-result _meta #741 asked for opt-in logging or a configurable logger, and noted that full payloads, including tool-result _meta, reach the console. Its filer closed it without a change.

Proposal

Make transport logging opt-in through an options argument:

new PostMessageTransport(eventTarget, eventSource, { logger?: Pick<Console, "debug"> })

Log nothing when logger is absent. The console.error for a malformed JSON-RPC message can stay. The third argument keeps the existing constructor compatible.

Happy to open a PR if this direction works.

Seen on 1.7.5; unchanged on main as of v2.0.0.