Problem

When running Coder on Kubernetes with an internet-facing load balancer, workspace agents
cannot download the Coder binary or connect to the server because the bootstrap script uses
CODER_ACCESS_URL for both browser access and agent communication.

In our setup:

• Coder server runs on EKS with an internet-facing ALB restricted to VPN CIDRs
• Users access Coder UI via https://coder.example.com through the ALB
• Workspace agent pods run in the same cluster but cannot reach the ALB's public IP from
  within the VPC (traffic would need to hairpin through NAT Gateway, and the ALB security group
  only allows VPN source IPs)

The agent bootstrap script (provisionersdk/scripts/bootstrap_linux.sh) uses ${ACCESS_URL} for
both binary download and CODER_AGENT_URL:

BINARY_URL=${ACCESS_URL}bin/coder-linux-${ARCH}
# ...
export CODER_AGENT_URL="${ACCESS_URL}"

And ACCESS_URL is set from s.AccessURL in provisioner/terraform/provision.go:

env = append(env, "CODER_AGENT_URL="+metadata.GetCoderUrl())

where GetCoderUrl() always returns CODER_ACCESS_URL.

Expected behavior

CODER_AGENT_URL is already a recognized environment variable on the agent side (cli/root.go),
but setting it as a server-side environment variable has no effect on the provisioner's
CoderUrl.

I'd expect that if CODER_AGENT_URL is set on the server, it should be used as the CoderUrl
passed to the provisioner, overriding CODER_ACCESS_URL for agent bootstrap and communication.

Workaround

We work around this by adding NAT Gateway EIPs to the ALB security group, so that pods can
reach the internet-facing ALB via hairpin routing (Pod → NAT Gateway → ALB → Coder). This
works but adds unnecessary network overhead for what should be cluster-internal
communication.

Use case

This is a common Kubernetes pattern: external users access services through an
internet-facing load balancer, while internal pods communicate via ClusterIP services.
Coder's current design assumes CODER_ACCESS_URL is reachable from both browsers and agents,
which isn't always the case.