Clarify denyOut semantics for sandbox-local MMDS (169.254.169.254)

Start at the pinned commit's packages/envd/internal/host/mmds.go and mmds_route_linux.go, tracing PinMMDSRoute and its /init verification behavior. Done means the supported contract answers the three questions and identifies any documented, testable isolation boundary without generalizing from the single diagnostic.

Question about the security semantics of outbound network controls and sandbox-local MMDS.

In one hosted sandbox diagnostic, created with secure:true, allowPublicTraffic:false and network.denyOut:["169.254.169.254/32"], TCP port80 and the MMDS endpoint remained reachable. Following envd's documented source protocol (PUT /latest/api/token with X-metadata-token-ttl-seconds:60, then GET / with X-metadata-token) returned HTTP200. The JSON keys were exactly instanceID, envID, address and accessTokenHash. The instance/template identifiers matched the sandbox/template used for this diagnostic. No values or credentials are included here. The sandbox was killed afterward.

Pinned source inspected: a1b5bd74dc5e4a6a35e4dba0e63e08a8c04c9de0, packages/envd/internal/host/mmds.go and mmds_route_linux.go. PinMMDSRoute appears to preserve access to this endpoint for /init verification.

Could you clarify:

1. Is sandbox-local MMDS intentionally exempt from denyOut, including TCP? Is there a supported way to deny user-workload access without breaking envd initialization?
2. Is this address guaranteed to resolve only to sandbox-scoped MMDS, never host/cloud-instance metadata or IAM/service-account credentials, across supported runtime/network configurations?
3. What is the supported, testable isolation boundary for cloud-host metadata credentials? Are there documented protected paths/redirect handling or provider conformance tests we can reference?

This is a request for the supported contract, not a claim of exposed host credentials. Our single diagnostic does not prove the behavior of all paths or deployments.