Prevent exact socket reads from duplicating bytes with MSG_PEEK #904

Problem

net_recv_exact and net_recv_exact_io advance the output cursor after a peek but do not consume or advance the socket data. They repeatedly copy the same queued prefix and report a complete read that never existed.

Reproduction

Audited on Linux amd64 at 53bb5809cf32d29f5a5a9d313ffa332ea3cd4beb, whose tracked tree matches canonical master c5ab63f9eec388c75b00f5cd59eae28a45a9b39f. Compiler built with Rust 1.89.0, LLVM 21, and the checkout std; Whale is locked to 020d2a4. Executed with a local Python socket.socketpair() and an inherited descriptor. The peer queued only b"ab" and stayed open. A Wave program called both helpers with a four-byte destination and Linux MSG_PEEK=2:

import("std::net::socket_base")::{net_recv_exact, net_recv_exact_io};
import("std::net::error")::{NetIoResult};
fun main() {
    var buffer: array<u8, 4>;
    var count: i64 = net_recv_exact(3, &buffer[0], 4, 2);
    println("count={} bytes={} {} {} {}", count,
        buffer[0], buffer[1], buffer[2], buffer[3]);
    var result: NetIoResult = net_recv_exact_io(3, &buffer[0], 4, 2);
    println("count={} eof={} error={}", result.count, result.eof, result.error.kind);
}

Use the actual socket fd in place of 3 and subprocess.run(..., pass_fds=(fd,)). Observed: count=4 bytes=97 98 97 98; the result helper also reports count=4, eof=false, error=0. Python's subsequent peek still sees only b"ab". No external network endpoint was used.

Scope

Start at the accumulating recv loops in std/net/socket_base.wave. Keep ordinary consuming reads, partial progress, EOF, and native errno behavior. Decide whether exact peeking is supported or incompatible flags are explicitly rejected; neither path may fabricate bytes or consume data contrary to MSG_PEEK.

Completion criteria

• Two queued bytes cannot become a successful four-byte abab result.
• Both exact-read APIs consistently handle or reject peek flags without changing the queued data unexpectedly.
• Regression coverage includes partial availability, would-block/timeout as applicable, ordinary reads, and supported platform flag values.

Please mention @LunaStev to discuss the design before starting implementation.