offload dns resolution off the green worker

[kacy]

summary

getaddrinfo is synchronous and there is nothing to poll, so a name lookup made from a green task held the worker os thread for its whole duration. every other task pinned to that worker stalled behind it. sockets already yield through the epoll reactor, which left dns as the one blocking step on the common client path, since every grpc, http, and database dial starts with one.

the lookup now goes to a small pool of ordinary blocking threads while the calling task parks. a pool thread wakes it when the answer is ready, through the same park/wake handshake netpoll uses for socket readiness, so a wake that lands before the task finishes suspending is recorded as pending rather than lost. the pool is capped at four threads and grows only when nothing is idle, so a program that resolves one name at a time runs one thread and a program that never resolves under green starts none.

the os-thread backend is untouched. resolve checks the backend and calls to_socket_addrs inline there, where blocking a thread is what a thread is for and a pool would only add a handoff. a numeric address also skips the pool, because to_socket_addrs parses one in place with no syscall to block in and dialing a literal ip is common.

failure behaviour is unchanged. a resolver error and an empty answer both come back as no addresses, which green_connect turns into 0 and pith_dns_resolve into null, exactly as before. a panic inside a lookup is caught and reported as a failed lookup rather than stranding the parked task, and if no pool thread can be started at all the caller resolves inline rather than parking on an answer that will never come.

the measurement

a program with two green tasks under PITH_GREEN_WORKERS=1: one resolves 40 uncached names, the other runs a fixed cpu loop and reports when it finished. on one worker the cpu task can only overlap the lookups if the resolving task gives the worker back.

seven interleaved pairs, swapping only target/release/libpith_runtime.a between arms so the driver binary is identical:

                     cpu task finished at
before   1063  928  993  902  982  1017  939 ms
after     425  415  418  415  418   414  417 ms

the cpu task's own runtime, measured alone, is 413-418 ms. before the change it always finished last and always at roughly its own time plus the whole dns batch; after it finishes at its own time while the resolver is still working (the resolver finished at 903-1010 ms in those same runs). so the worker is genuinely free during a lookup rather than the lookups merely getting faster.

what was tested

• cargo build --release at the repo root and cargo test --release -p pith-runtime, including six new unit tests for the pool: it answers a lookup, reports failure as no addresses, never exceeds its thread cap under a burst of jobs, stays inline outside a green task, short-circuits literal addresses to the same answer to_socket_addrs gives, and still rejects an out-of-range port through the literal path
• make test: 99/99 examples, 261/261 native regressions, 261/261 self-hosted regressions, plus the invalid, parity, cli, and ir-contract checks
• PITH_GREEN=1 make verify-green-corpus: 261/261 at the default worker count and again pinned to one worker (260 before this branch; the new case brings it to 261)
• make docsite-check
• the new tests/cases/test_dns_resolve_and_dial.pith prints identical output under os threads, green at one worker, and green at the default worker count