Hash agent-mode jar members through the shared streaming zip comparator instead of buffering each member #914

[agent] Filed by the scheduled architecture audit routine (CLI and core). Register: register comment.

Kind: refactor (performance; one duplicated routine). Source: new finding, register row C51. It is the agent-mode twin of C01 (#569, fixed by #587).

Problem (main @ 9c43dfc)

There are two routines that hash named zip members with Git SHA-256 and compare them to a patch record, and they have drifted apart.

Vendored (streams): vendor/common.rs::zip_bytes_match_after_hashes. Since #587, following the maintainer's direction on #569, it streams each member through compute_git_sha256_from_std_reader:

if !compute_git_sha256_from_std_reader(entry.size(), entry)
    .is_ok_and(|hash| hash == info.after_hash)

Agent mode (buffers): patch/jvm_jar.rs::verify_member_bytes inflates every patched member into a Vec and then hashes it:

let mut entry = a.by_name(member).ok()?;
let mut buf = Vec::new();
entry.read_to_end(&mut buf).ok()?;
Some(buf)
// …
content.map(|c| compute_git_sha256_from_bytes(&c))

verify_member_bytes runs on every agent-mode Maven/Gradle jar record: in apply verification through verify_members (apply.rs L397–L401), in vex verification (vex/verify.rs L344–L349), in apply_jar_swap (L464) and in the rollback restore (L634). That covers every copy in ~/.m2 and in each Gradle cache hash directory.

Measured (temporary core lib test, debug build, peak RSS from /proc/self/status VmHWM, run twice with the same result): a jar holding one deflated 1 GiB member (1.0 MB on disk) plus one small member, with a record for the big member.

Symptoms

None filed. Impact: memory grows with the inflated member size on each agent-mode jar verification, in apply, rollback and vex. This is the same defect #569 fixed for vendored mode, so it is per the maintainer a performance problem, not a trust one; no cap is proposed. Size: ~20 lines.

Proposed change

• Add one helper next to the stream hasher, for example hash::git_sha256::zip_member_git_sha256(archive, name) -> Option<io::Result<String>>. It looks up a member and streams it through compute_git_sha256_from_std_reader.
• zip_bytes_match_after_hashes and verify_member_bytes both call it.
• Deleted: the buffered read_to_end closure in verify_member_bytes, and the duplicate lookup-and-hash loop in zip_bytes_match_after_hashes.
• Keep each caller's lookup rules as they are: vendored refuses keys that fail is_safe_relative_subpath, and agent mode reports a missing member as NotFound/Ready.

Size and scope

• hash/git_sha256.rs, patch/jvm_jar.rs, vendor/common.rs: about 40 changed production lines.
• Out of scope: unpatched_members and vendor::verify::read_zip_bytes_to_map (they need whole member bytes to rebuild the jar); the vendored per-file readers in vendor/mod.rs (the sibling area); hash case (Agent-mode apply and rollback reject a manifest hash in uppercase hex that blob download accepts as valid #707); the digest helpers that Route Gradle digests through utils::digest #878 and sbt, Mill and scala-cli support in agent, hosted and vendored modes #690 touch in jvm_jar.rs.

Acceptance criteria

• verify_member_bytes doesn't buffer a member: rg "read_to_end" crates/socket-patch-core/src/patch/jvm_jar.rs prints nothing in the verify path.
• A regression test in jvm_jar builds (streaming) a jar with a large zero-filled deflated member and checks the VerifyResult for it. The peak-RSS check can stay out of CI, as Stream ZIP member hashes during vendored verification #587's did.
• The existing jvm_jar tests, patch::apply and vex::verify jar tests, the Maven/Gradle agent e2e tests and vendor::common tests stay green.
• cargo clippy --workspace --all-features -- -D warnings is clean.

Dependencies

None. It touches jvm_jar.rs lines that #878 and #690 don't edit (those change the private sha256_hex/sha1_hex).