stdio transport: UTF-8 double-encoding on output; silence on non-ASCII input

[noizu]

Found by The Robot Reviews' D-030 test pass (AC1 real-stdio integration test). Raw wire-capture evidence lives in the test comments: the-robot-reviews/app/test/trr_site/doc_pointers/client_stdio_integration_test.exs.

1. OUTPUT double-encodes non-ASCII

Each UTF-8 byte of a glyph is emitted as a Latin-1 codepoint: F0 93 85 9C leaves the server as C3 B0 C2 93 C2 85 C2 9C. Every client response containing a hieroglyph token is corrupted — and the tokens are the system's core citation identifier.

2. INPUT: non-ASCII requests get no response

A request carrying non-ASCII (e.g. token-keyed lookup — the core citation flow) never produces a response; the server stays silent until the client times out (30s in our transport).

3. Minor: generate omits description

Real generate stores description and lookup returns it, but the generate result omits the field; it is also required in real but optional in our FakeTransport (test-fidelity divergence).

Suggested fix direction

The transport should treat stdin/stdout as raw binary (:binary mode / port with stream lines) rather than Unicode codepoint lists — the double-encode pattern is the classic :unicode/Latin-1 list mismatch.

Repro: TRR's client_stdio_integration_test.exs auto-discovers a sibling checkout and compiles out when absent, so it doubles as a cross-repo repro harness.

[noizu]

Local reproduction (no MCP client needed)

MIX_ENV=dev mix run -e '
:io.setopts(:stdio, binary: true, encoding: :latin1)
IO.binwrite("hieroglyph test: ⟦𓊄𓍂𓅱𓁮⟧\n")
' 2>&1 | od -c | head

Output contains the double-encoded bytes (303 260 for the 0xF0 lead byte, etc.) — even with :io.setopts(:stdio, binary: true, encoding: :latin1) applied before the write. So the fix is not the naive setopts; the transport likely needs to bypass the io protocol entirely (:file.write/2 on the raw stdout fd) or set the group-leader opts on the correct device process.

Direction for the fix

• OUTPUT: Noizu.MCP.Transport.Stdio.send_message/3 uses IO.binwrite(:stdio, ...) — raw bytes, but the io layer re-encodes latin1-interpreted binaries when the device is in UTF-8 mode. Candidates: raw fd write, or :file.write(:erlang.whereis(:stdio), bytes) semantics.
• INPUT: IO.binread(:stdio, :line) stalls on multibyte sequences (server silence until client timeout) — same device-mode root cause, opposite direction.
• The stdio framing tests should grow a non-ASCII round-trip case: emit ⟦𓊄𓍂𓅱𓁮⟧ and read it back byte-identical.