node:dns + node:dgram are loopback-only fakes — implement real network I/O behind a deterministic-mode flag #4911

What lies

node:dns, node:dns/promises, and node:dgram are deterministic loopback-only by design — the full Node API surface is registered and callable, but no real network I/O ever happens. Callers get plausible-shaped results (loopback answers, empty record sets, in-process UDP delivery), so code "works" in tests and silently fails against real infrastructure.

Evidence (current main):

• crates/perry-runtime/src/dns.rs:3-5 — "These helpers intentionally avoid external name resolution. They provide the Node-compatible surface Perry's fixtures need using deterministic loopback answers plus empty record sets for names we do not control." All of lookup, resolve4/6/Any/Caa/Cname/Mx/Naptr/Ns/Ptr/Soa/Srv/Txt, reverse are affected.
• crates/perry-runtime/src/dgram.rs:1-6 — "Perry does not expose host UDP sockets yet. This module implements the Node-shaped unicast subset against an in-process loopback registry." Multicast membership ops are accepted with no OS side effects.

Why it matters

Severity: SILENT-LIE. Any real service that connects by hostname (every DB driver, HTTP client using dns.lookup, service discovery) or uses UDP (statsd, syslog, DNS itself) gets empty/loopback results with no error. This blocks production-shaped usage while looking supported.

Acceptance

• Real resolver behind the existing surface (getaddrinfo for lookup; a real DNS client, e.g. hickory-resolver, for the resolve* family), keeping the deterministic mode for parity tests behind an env flag (e.g. PERRY_DETERMINISTIC_NET=1 used by CI).
• Real host UDP sockets for dgram unicast; multicast either real or throwing ERR_SOCKET_*, never silent no-op.
• Until implemented: entries flagged stub: true in the API manifest and first-call perry_stub_warn diagnostics emitted.