Closed guest loopback sockets never released their kernel socket-table slots
until process exit (measured: vm_sockets highWater 81 for a workload whose
true concurrency is ~9), so connection-churning guests hit EAGAIN 'maximum
socket count reached' at ~250 cumulative sockets.

- Bridge: natural FIN close finalization now releases the sidecar/kernel
  handle (idempotent, once), deferred until JS readable buffers drain so
  buffered data is never dropped.
- Sidecar: net.poll close handling closes the underlying TCP/Unix handle when
  removing map entries; explicit close paths funnel through an idempotent
  kernel close (ENOENT tolerated); the TLS-mode close path no longer skips
  kernel close for kernel-backed sockets.
- Guest fetch() now uses a bounded per-call undici dispatcher instead of the
  process singleton whose pooled clients went stale against released sockets
  and hung (also fixes a pre-existing hang: repeated fetch over a kept-alive
  loopback connection). Revisit pooling when host->guest socket event push
  (#178) lands.
- Regression test: guest churns 3x max_sockets connections with closes.

Full net family at 30 iterations passes (previously EAGAIN at tcp_concurrent_4):
fetch 2.59ms, tcp_echo 3.57ms, tcp_concurrent_4 4.91ms guest p50; leak probe
highWater 81 -> 17 with depth returning to 0.

…yfill

- _fsReadRaw/_fsWriteRaw/_fsWriteFileBinaryRaw were added to
  bridge-contract.json by the raw fs fast path without browser facade
  coverage, failing check:bridge-contract ever since.
- Regenerate wasi-polyfill.ts from the shared native WASI runner (stale after
  the create-parent-aware path resolution fix landed in the runner).

Restores a green 'pnpm --dir packages/browser check-types'.