messaging: two parallel message systems (MessageQueue vs MessageBus) duplicate buffering/renderer/request-response logic and have already drifted

Files: code_puppy/messaging/message_queue.py (MessageQueue / UIMessage) vs code_puppy/messaging/bus.py (MessageBus / TextMessage et al.)

Severity: Medium (architecture / DRY - "one obvious way to do it")

The messaging package contains two parallel message systems, each with its own:

• message envelope (UIMessage dataclass + MessageType enum vs the pydantic AnyMessage family in messages.py)
• thread-safe queue with drop-oldest-on-full logic (message_queue.py emit() ~line 116 vs bus.py emit() ~line 118)
• startup buffering + _has_active_renderer flag + mark_renderer_active/inactive (both files, nearly identical method names)
• sync->async bridging (MessageQueue._process_messages thread + call_soon_threadsafe vs MessageBus.get_message polling)
• human-input request/response correlation (create_prompt_request/wait_for_prompt_response with threading.Events vs request_input/provide_response with asyncio.Futures)
• module-level singleton + emit_* convenience functions

tools/common.py consumes the queue-console flavor (get_queue_console) while the tools themselves emit through the bus (get_message_bus()), so a single tool call's output flows through both systems. Every behavior fix (buffer cap, drop policy, renderer detection) must be made twice, and they have already drifted (the bus caps its startup buffer at maxsize; the queue's _startup_buffer grows unbounded in headless mode).

Suggested fix: declare one of the two the canonical pipe (the bus appears newer and richer), port the remaining consumers of MessageQueue (queue_console, renderers) onto it, and delete or thin the other into a compatibility shim. Short of that, at least extract the shared drop-oldest/startup-buffer logic into one helper and cap the queue's startup buffer like the bus does.

Filed by Zen Reviewer B (code-puppy-60635a)

Read code_puppy/messaging/message_queue.py and code_puppy/messaging/bus.py, then trace get_queue_console in tools/common.py and the renderers alongside get_message_bus(). Decide whether MessageBus becomes canonical or whether shared buffering logic is extracted. Done means the remaining consumers use one consistent message path, duplicate behavior is removed or shimmed, and startup-buffer limits no longer drift.