Allow approved domain families in network enforcement policies

[JimBugwadia]

User outcome

Operators can allow destinations under an approved domain family without enumerating every subdomain.

Current behavior

dns supports left-wildcards for reporting only. network supports exact external names via DNS snooping but rejects wildcards. #228 changes open/exec hooks, not DNS interception.

Scope

• Define network left-wildcard matching and whether the apex is separate, consistent with dns reporting.
• Match observed DNS answers to selected policy suffixes and program bounded destination permissions.
• Reject unsupported wildcard positions and disclose UDP/53, encrypted DNS, shared-IP and hardcoded-IP limits.

Acceptance

• An allowed subdomain works under default deny; unrelated names and suffix lookalikes do not gain permission.
• Apex, CNAME, mixed case, trailing dot, TTL expiry and policy changes are tested.
• Unselected pods do not enter the DNS question observer.
• Tests prove destination blocking, not just a Report.

Dependencies and boundaries

Depends on #240 for lifetime/conflict semantics. #65 is required for a dual-stack destination-containment claim. Keep dns observation-only; destinations belong to network.

Validation and completion

• Table-driven tests pin the stated invariant, including invalid input and policy updates.
• For code changes: make build and make test; significant changes also require make kind-install and a targeted behavioral check. Pipeline, collector, evaluator, or reporter changes require make smoke-quickstart.
• Kernel changes use the pinned BPF builder, generated-artifact verification, verifier loading, and allowed/denied behavior tests on supported hook paths.
• Update DESIGN, development guidance where affected, and the RuntimePolicy reference and limits. Every rejected user rule must reach an operator log and policy condition; count every observation drop. Preserve the reporter redaction boundary.