enhancement: net and http modules for the nodejs runtime

## Summary

The nodejs runtime has no way to reach a network, so nothing built on it can be a client or a server. wasmrun is building the host half now (a socket proxy for the browser VM shipped in its 0.24.1 and 0.24.2, native sockets in the interpreter are next), and when that lands the runtime is the missing piece: there is no module for a script to call.

## Current state

- The [`builtins` table](https://github.com/anistark/wasmhub/blob/12f0f6a400b3a6529e6dddf4ffa8db0a439e69ea/runtimes/nodejs/main.js#L2905-L2925) has no `net`, `http`, `https`, `dgram` or `tls`, so `require('net')` fails as an unknown module rather than as an unsupported one.
- [`features.txt`](https://github.com/anistark/wasmhub/blob/12f0f6a400b3a6529e6dddf4ffa8db0a439e69ea/runtimes/nodejs/features.txt) ends at `node-test`, `exports-map`, `named-stack-frames`: nothing network-related is claimed, which matches the code.
- [`wasi_stubs.c`](https://github.com/anistark/wasmhub/blob/12f0f6a400b3a6529e6dddf4ffa8db0a439e69ea/runtimes/nodejs/wasi_stubs.c) declares no `sock_*` symbol, so nothing is stubbed out either.
- `zlib`, `worker_threads` and `child_process` show the established pattern for a module the sandbox cannot support: [`unsupportedModule`](https://github.com/anistark/wasmhub/blob/12f0f6a400b3a6529e6dddf4ffa8db0a439e69ea/runtimes/nodejs/main.js#L2846-L2858) gives a named module that throws a clear reason. Networking is the opposite case: it can be supported, given imports.

## Proposed change

Implement `net` against the host's WASI socket imports, then `http` on top of it. Suggested phasing, each independently useful:

1. `net`: `createServer`, `Server#listen`, `Socket` (connect, `data`/`end`/`error` events, `write`, `end`), built on the same stream and events modules already in the runtime
2. `http`: `createServer` and `request`/`get` over `net`, enough for a request/response cycle with headers and a body
3. Optional later: `dgram`, and `tls` if the host terminates TLS rather than the guest

Two constraints worth deciding early:

- **WASI Preview 1 has no outbound connect.** Only `sock_accept`, `sock_recv`, `sock_send` and `sock_shutdown` are standard, and only on a descriptor that is already listening. `sock_open`, `sock_bind`, `sock_connect` and `sock_listen` are WASIX-style extensions, so the exact import names and signatures are a contract between this runtime and the host. wasmrun is defining them in its 0.24.6 slice; worth agreeing on the shape before either side builds to it.
- **The runtime is synchronous.** QuickJS runs to completion inside one host call, so `net` needs imports that block, which the wasmrun interpreter can do natively. The browser VM cannot block today, which is tracked separately on the wasmrun side and does not affect this issue's design.

## Acceptance criteria

- `require('net')` returns a working module, and a script can bind a port, accept a connection, read a request and write a response
- `http.createServer` serves a request from an ordinary client, and `http.request` fetches from an ordinary server
- A connection the host refuses on policy grounds surfaces as an `error` event with the host's reason, not as a hang or a silent close
- `features.txt` gains the features in the same change that implements them, per the note at the top of that file
- A host without the socket imports still loads the runtime: the modules should degrade to the `unsupportedModule` behavior rather than failing at instantiation

## References

- wasmrun networking issue: https://github.com/anistark/wasmrun/issues/99
- wasmnet, the proxy used for the browser VM: https://github.com/anistark/wasmnet
- WASI Preview 1 socket functions: https://github.com/WebAssembly/WASI/blob/main/legacy/preview1/docs.md
- WASIX socket extensions, prior art for the outbound calls: https://wasix.org/docs/api-reference