gl: uncapped success-body reads let a malicious node exhaust client memory

[euxaristia]

Summary

Body caps (read_body_capped, the codebase's INV-6 "reads must be bounded") are applied only on error paths (peer.rs, sync.rs, whoami.rs). Success bodies are buffered to completion with no cap: crates/git-remote-gitlawb/src/main.rs:257 (info/refs), :569 (each pack negotiation round), crates/gl/src/clone.rs:327 (resp.json()), :377 (per-envelope bytes), crates/gl/src/mcp.rs:796.

Impact

A hostile node answering a fetch, clone, or MCP call with an oversized 200 body causes full buffering and client memory exhaustion on the most basic operations. A MITM on a plaintext GITLAWB_NODE reaches the same sinks (see #413/#443 for the scheme gap).

Remediation

1. Apply read_body_capped (or streaming with a hard cap) to success bodies on the refs, pack, clone, and MCP paths.

Proposed labels: kind:security, crate:gl, crate:git-remote.

[beardthelion]

Recalibrating to sev:medium. Reaching these sinks requires the operator to point gl or the remote helper at a hostile node (the plaintext-remote path is tracked separately in #413). That precondition puts it in the same band as #418 rather than the anonymously-triggerable issues. The remediation is unaffected; success bodies still need the cap.