Support bidirectional host-loopback access

Support network.ingress.hostLoopback: "allow" without requiring callers to supply a port-forwarding list.

Example	Expected behaviour
Host-loopback access allowed	The workload can reach services on host loopback, and the host can reach services listening inside the workload.
Host-loopback allowed, `ingress.default: "deny"`	Host-loopback connections work, but other private-network inbound connections remain blocked.
Host-loopback access denied	Block both directions between host loopback and the workload.
Host-loopback denied with a configured proxy	Preserve only the existing outbound exception to the exact TCP proxy endpoint.

Do not expose workload listeners through the host's LAN/public interfaces. Keep loopback communication between processes inside the same sandbox separate from host-loopback access.

Verify both directions with real workloads. Existing explicit TCP/UDP forwards should continue to work.

MXC schema requirement: network.ingress.hostLoopback, with semantics defined in the networking contract.