Ruby: debuggee stdout/stderr is not captured (rdbg child stdio bypasses DAP output events)

[debugmcpdev]

Context

Follow-up from #218 (debuggee output forwarding). The fix for #218 buffers DAP output events per session and exposes them via the get_output tool and the debug://sessions/{id}/output resource. This works for adapters that emit debuggee stdio as DAP output events (verified: Python via redirectOutput: true, JavaScript via outputCapture: 'std', Java via the JDI bridge's stream pumps; Go/.NET expected to work via console: 'internalConsole').

Ruby is the outlier.

Problem

buildAdapterCommand runs rdbg --open --host --port -c -- <target> (packages/adapter-ruby/src/ruby-debug-adapter.ts:234-266) — the debuggee is a child of the rdbg process the proxy itself spawns, and DAP travels over a separate TCP socket. The debuggee's stdout/stderr land on the adapter process's own pipes, which are currently drained as log lines in src/proxy/dap-proxy-adapter-manager.ts:152-165 (stdout at debug level, stderr at error level) and never become DAP output events.

Result: get_output legitimately returns zero entries for Ruby sessions.

Suggested direction

Synthesize output events from the adapter process's stdio in the launch-mode Ruby path — e.g. in the adapter-manager stream consumers, forward line-buffered chunks to the same channel the DAP client's output handler feeds (categories stdout/stderr). Care needed to exclude rdbg's own diagnostics if it writes any to stderr before the session connects, and attach mode (remote socket) has no adapter process at all, so this is launch-mode only.

Acceptance

A Ruby launch-mode session running a script with puts/warn markers surfaces both via get_output (categories stdout/stderr), consistent with Python/JavaScript/Java behavior.