Clarify denyOut semantics for sandbox-local MMDS (169.254.169.254)

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.

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.