Fix exposed service host.v1 loopback dial timeouts

[casey-brooks]

Summary

agents-orchestrator PR #189 E2E run 26468441507 fails after bootstrap #539 in TestAgentExposeLifecycle_ListAddRemove when an external Ziti app identity calls:

GET http://exposed-d683b26a-d8b6-4240-956d-e44352c427cf:3000/index.html

The request times out with context deadline exceeded.

Investigation

This does not appear to be a Kubernetes Service/DNS/Endpoint issue. Expose creates an OpenZiti service, not a Kubernetes Service named exposed-<id>. Connectivity is through OpenZiti DNS/intercept and host.v1 forwarding.

Evidence from run 26468441507:

• TestAgentExposeListExec passes.
• TestAgentExposeLifecycle_ListAddRemove successfully runs expose add and sees the exposure listed as active.
• The Ziti controller initially reports service 1OXk31PwNckQY5TU51dVVJ has no terminators, then later attempts to route to a terminator for service exposed-d683b26a-d8b6-4240-956d-e44352c427cf.
• Circuit creation then fails repeatedly with router-side timeout waiting for message reply while sending a dial request to the workload-side SDK terminator.
• The E2E HTTP server binds to 127.0.0.1:3000 inside the workload pod.

Current expose host.v1 config targets Address: "localhost". In this path, OpenZiti host.v1 dialing happens in the workload ziti-tunnel process. If localhost resolves to IPv6 loopback first while the workload server is IPv4-only, host dialing can hang/fail and surface as the observed route/dial timeout.

Expected behavior

Expose should target the workload loopback listener deterministically and the E2E request should complete.

Fix direction

Pin generated host.v1 configs for exposed workloads to IPv4 loopback 127.0.0.1 instead of localhost.

References

• agents-orchestrator PR: fix(devspace): wait for buf config sync agents-orchestrator#189
• E2E run: 26468441507
• Bootstrap PR preceding run: Bump authorization to 0.5.4 and runners to 0.5.11 bootstrap#539