[bug] Avoid duplicate and unbounded buffering in deploy and remote RPC transport paths

[sizumita]

Affected component

other

Summary

Several admin/client transport paths still over-buffer data in memory. The deploy and remote RPC clients read full responses into a Vec<u8> and then copy frames again into Vec<Vec<u8>>, and the local proxy path keeps stderr in an unbounded buffer.

Steps to reproduce

1. Use a deploy/admin path that returns a large framed response.
2. Observe that the client reads the full response into memory and then copies frame payloads again during decode.
3. For local proxy execution, point stderr at a noisy process and observe unbounded accumulation.

Expected behavior

Transport code should avoid duplicate full-response copies and should keep stderr buffering bounded.

Actual behavior

The current code reads whole responses first, decodes into owned frame vectors even when only the first frame is used, and accumulates local proxy stderr without a fixed cap.

Version

3f1c39e

Environment

other

Resource impact (optional)

peak RSS can spike because responses are read whole, then copied again during frame decode; local proxy stderr is also unbounded.

Additional context

Evidence:

• crates/imagod-control/src/service_supervisor/remote_rpc.rs:304
• crates/imagod-control/src/service_supervisor/remote_rpc.rs:320
• crates/imagod-control/src/service_supervisor/remote_rpc.rs:346
• crates/imagod-server/src/protocol_handler/codec.rs:29
• crates/imago-cli/src/commands/deploy/mod.rs:41
• crates/imago-cli/src/commands/deploy/mod.rs:1693
• crates/imago-cli/src/commands/deploy/mod.rs:1368
• crates/imago-cli/src/commands/deploy/mod.rs:1377

Suggested direction:

• Decode framed responses incrementally or via borrowed slices rather than Vec<Vec<u8>>.
• When only the first frame is needed, stop after the first frame.
• Replace local proxy stderr buffering with a bounded tail buffer and avoid extra clones on retrieval.