runner: expose effective DNS resolvers for orchestrators

[sixtoad]

Problem

Walk generates Cedar network policy before launching Leash. For container runs it can inspect the runtime's effective /etc/resolv.conf, but native Leash currently replaces the governed workload's resolver configuration with 1.1.1.1 and 8.8.8.8. Leash exposes no machine-readable capability that tells an orchestrator which resolver addresses the workload will actually use.

This was discovered while implementing Walk #54. Authorizing host resolvers for native runs would deny the DNS traffic Leash redirects to its public resolver set, while hard-coding Leash internals in Walk would duplicate ownership and drift.

Required contract

• Leash is the source of truth for the effective resolver set it installs or preserves for each runtime.
• Expose that set through a stable, bounded, machine-readable CLI capability that does not launch a workload or require credentials.
• The result must distinguish native and container behavior where they differ and be deterministic/deduplicated.
• Failure to determine the effective resolver set must be explicit so callers can fail closed.
• Keep human diagnostics on stderr and structured output byte-pure on stdout.
• Do not add reversed-address compatibility for lsm/network: fix IPv4 byte order for connect events and literal policy matching #74 or broaden network policy.

Acceptance

• Given a native run whose resolver file Leash rewrites, when Walk queries the capability, then it receives exactly the addresses Leash will install.
• Given a container runtime whose resolver is runtime-managed, when queried in that context, then the capability reports the effective runtime resolver contract or explicitly delegates discovery without claiming the native set.
• Given malformed or unavailable resolver state, then the command exits non-zero with no partial success payload.
• Unit tests cover IPv4, IPv6, ordering, deduplication, malformed input, and machine-output separation.
• Documentation defines ownership and compatibility for orchestrators.

Dependency

This is the upstream prerequisite for Walk #54. The Walk implementation and real Docker E2E are otherwise green.