pageant: Out-of-bounds read / oversized allocation in `pageant` MemoryMap::read via a malicious Pageant agent (Windows)

## Summary `MemoryMap::read` in the `pageant` crate (part of the russh workspace, used by russh's SSH-agent client on Windows via `AgentClient::connect_pageant`) copies a **peer-controlled** number of bytes out of an 8192-byte shared-memory view with **no bounds check** — unlike the sibling `MemoryMap::write`, which correctly rejects oversize access with `Error::Overflow`. The byte count comes straight from a `u32` length prefix that the responding "Pageant" process writes into the shared mapping. A malicious local process that answers as the Pageant agent can therefore cause: - an **out-of-bounds read** past the 8 KiB view (access violation → process crash; or disclosure of adjacent process memory if the following page is committed) - an allocation of up to **~4 GiB** from a single `u32` (`vec![0; n]`). This was reproduced **end-to-end against the real, unmodified `pageant` crate** (not a model) on `x86_64-pc-windows-gnu` under Wine; see "Proof of concept". ## Impact - **Availability / DoS (reliable).** `MemoryMap::read(size)` walks off the end of the 8192-byte view and faults on the next, unmapped page — an `EXCEPTION_ACCESS_VIOLATION` that crashes the russh SSH client. Independently, a `size` near `u32::MAX` drives a ~4 GiB `vec![0; n]` before any copy. - **Confidentiality (conditional).** If memory immediately after the mapped view happens to be committed, `read` returns those adjacent bytes to russh as the "agent response", which russh then parses as agent identities/sig