Bound IOCP staging allocations independently of caller buffer capacity

`iocp_start_io` allocates and zeroes `length` bytes for every operation, accepting sizes up to 4,294,967,295 bytes. Writes additionally copy the complete requested range. A large read capacity therefore reserves an equally large second buffer even when only a small message will arrive. Multiple outstanding requests amplify this cost.

Owned kernel-visible storage is intentional for cancellation safety; this report is about bounding that storage, not removing ownership protection.

Source evidence at the head of #520:

- [std/sys/windows/iocp.wave:69](https://github.com/wavefnd/Wave/blob/2ae0a91c57fd76323124c0e4dff552adbfadbe1b/std/sys/windows/iocp.wave#L69) — `pub fun iocp_start_io`

Acceptance:

- [ ] Limit per-operation staging size or introduce another explicitly bounded ownership strategy.
- [ ] Keep short-read semantics and let read_exact/write_all advance correctly through partial operations.
- [ ] Measure allocation counts/bytes for bounded concurrent requests with large caller capacities and small actual transfers.
- [ ] Cover cancellation and allocation failure without releasing storage before its completion acknowledgement.

Related: #445. Native buffer lifetime must remain correct while reducing resource use.

Audit status: identified by static source inspection; the scenarios above have not been executed during this audit. This follows up the implementation introduced in draft PR #520.

Start at std/sys/windows/iocp.wave:69, the iocp_start_io entry point, and review the implementation introduced in draft PR #520 along with related issue #445. Measure bounded concurrent requests using large caller capacities and small transfers, then verify short reads, read_exact/write_all progress, cancellation, and allocation failure without releasing storage before completion acknowledgement.

Written by the indexing model from the issue text.