Self-managed Pylon discovery bypasses enabled backend routing

[along-2017]

Describe the bug

The self-managed stack defaults Pylon's discovery address to the main request-router Service even when backend routing is enabled. Discovery can advertise DNS-derived identities that the backend router cannot resolve for registration, leaving some request-router replicas without eligible workers and causing intermittent 404 no_eligible_candidates responses.

Steps or code to reproduce bug

1. Use a revision with the main-Service bootstrap default and enable the LLM addon with multiple Deployment-backed request-router replicas and backend routing enabled.
2. Leave global.workerEndpoints.llmRequestRouterAddress empty and deploy an LLM function.
3. Inspect Pylon discovery and registration: DNS-derived identities that differ from actual pod names are rejected by backend routing.
4. Send requests across the request-router replicas; replicas without registered workers can return 404 no_eligible_candidates.

Expected behavior

With backend routing enabled, the default bootstrap address uses backend-router discovery, which returns pod identities that registration can route.

Additional context

The fix belongs in deploy/stacks/self-managed/global.yaml.gotmpl. Proposed implementation: #1989. This issue covers bootstrap address selection; explicit-null automatic mode and advertised registration/QUIC dial-address changes are outside its scope.

Completion conditions:

• Select the backend-router Service when backend routing is enabled and the main Service when disabled.
• Preserve explicit worker-address overrides; both defaults use port 50071, with custom ports supplied in the full override address.
• Add render regression coverage for default selection, disabled backend routing, overrides, and port independence; update the deployment documentation.

---

By submitting this issue, you agree to follow our code of conduct and our contributing guidelines.