[tiptenbrink]

A large read no longer makes the adapter compute a checksum. The grader opens a loopback socket and passes its address to the adapter as body_sink, in place of body_result: "fingerprint". The adapter connects, copies the body it read into the connection, closes it, and reports its result without a body. The grader fingerprints the bytes as they arrive and adds body_length and body_crc64nvme_base64 to the result's value, where generated_body checks them as before.

Adapters reporting a CRC-64/NVME had to get its byte order right: the Azure SDK and the borink crate hand out little-endian bytes, and the fingerprint is big-endian. Two adapters needed a reversal, and one agent got it wrong. Now an adapter only copies bytes: io::copy into a TcpStream in Rust, a small socket helper in C++.

• The grader reads the sink on its own thread while the adapter runs, so neither side blocks, and wakes it with a connection it recognises by address when the adapter is done.
• A read that writes nothing to the sink, or opens it more than once, gets no fingerprint, so its generated_body check fails. A test covers an adapter that never writes to it.
• The cases are unchanged: large.json still says body_result: "fingerprint", so no live evidence needs a new run.
• The borink adapter is pinned at object-storage 55bde1e, which writes to the sink and passes all 30 large cases. The Azure C++ and AWS C++ adapters in the development repository pass all of theirs too.