fix(cli): forward TUIST_CACHE_ENDPOINT to the Xcode cache daemon

What

Forward TUIST_CACHE_ENDPOINT into the Xcode compilation cache (CAS) daemon’s launchd-agent environment.

Why

The runner-cache dispatch hands runners the private-network cache endpoint as a hard TUIST_CACHE_ENDPOINT override (runners_controller exports runner_cache_endpoint_url as TUIST_CACHE_ENDPOINT), and the binary module cache honors it. The CAS daemon is started by tuist setup cache as a launchd agent, which does not inherit the caller’s environment, so it never saw TUIST_CACHE_ENDPOINT and kept resolving the public endpoint via getCacheEndpoints. Result: the module cache used the private-network node while the CAS round-tripped every compilation unit to a public endpoint, leaving the Xcode cache net-negative on a full compile.

#11481 forwarded the client feature flags, on the theory that the kura flag would make getCacheEndpoints return the private endpoint. It does not: getCacheEndpoints returns account_cache_endpoints, which is deliberately the public, CLI-facing endpoint (a developer machine must be able to reach it); the private node is only ever handed out as the TUIST_CACHE_ENDPOINT dispatch override. A benchmark on a canary with #11481 plus the kura flag confirmed it: the CAS sent zero traffic to the private node and stayed at ~90s, identical to baseline.

Fix

Forward TUIST_CACHE_ENDPOINT into the agent environment when set, alongside the feature flags. No runner-side change is needed: the runner already receives the override for the module cache. Also corrects the #11481 comment, which claimed the feature flags alone route the CAS to the private network.

Validation

• New unit test asserts the override is forwarded into the agent environment.
• Existing tests unaffected (the override is only added when set).
• Re-running the benchmark on a canary with this change is the end-to-end check.

🤖 Generated with Claude Code