Clarify Stable IP change policy and DNS redirect language (#5056)

* Clarify Stable IP change policy and DNS redirect language

Rewrite "Changes to Stable IP ranges" to state the actual commitments:
once a region's ranges are published Temporal avoids adding to them and
has no plans to remove one, and any unforeseen add or remove comes with
six months of advance notice.

Remove the "Don't depend on DNS resolution behavior" callout from the
Stable IPs section. It named High Availability as the *only* case with
guaranteed DNS resolution, which is wrong now that Stable IPs is a second
case. The accurate version, listing both, already exists in "When
Namespace Endpoint DNS resolution is predictable" on the same page and in
the Namespaces page callout.

Replace "routes to" with "redirects via DNS to" where the docs describe
the Namespace Endpoint reaching an active region. The endpoint does not
proxy traffic; it is a DNS redirect.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* Update docs/cloud/connectivity/ip-addresses.mdx

* Apply suggestions from code review

Co-authored-by: Luke Knepper <lukeknepper@gmail.com>

* Apply suggestion from @lukeknep

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: lukeknep

docs/cloud/connectivity/ip-addresses.mdx

@@ -341,11 +341,6 @@ IP addresses are provided in IPv4 or IPv6 format with CIDR notation. At launch,
 
 :::
 
-:::note Don't depend on DNS resolution behavior
-
-Take a dependency on Temporal's published endpoints (the hostnames themselves), not on what they resolve to. The underlying IP addresses, CNAME chains, and resolution behavior can change at any time without notice. The **only** exception is the Namespace Endpoint for a Namespace with [High Availability features](/cloud/high-availability), which deterministically CNAMEs to its active region's regional record — see [Connectivity for High Availability](/cloud/high-availability/ha-connectivity) for details.
-
-:::
 ### How to connect using Stable IPs
 
 To connect to a Namespace with Stable IPs enabled:
@@ -432,9 +427,11 @@ Take note of the following:
 
 ### Changes to Stable IP ranges
 
-Temporal does not intend to make changes to published Stable IP ranges. In the rare exception that a Stable IP range needs to be added to or removed from the list, Temporal will communicate via targeted communication to affected Temporal Cloud users and the [Temporal Cloud changelog](https://temporal.io/change-log), and will give ample time for users to update their firewalls with the changed IPs.
+Once a region's Stable IP ranges are published, Temporal avoids adding new ranges to that region's list, and Temporal has no plans to ever remove a published range.
+
+If an unforeseen event requires Temporal to add or remove a region's published ranges, Temporal will give at least three months, and preferably six months, advance notice through targeted communication to accounts that have Stable IPs enabled. Changes to IP Ranges are publicly announced in the [Temporal Cloud changelog](https://temporal.io/change-log).
 
-Temporal will never route traffic to IP addresses that are not listed in the API response.
+Temporal never redirects Namespace Endpoints with Stable IPs to IP addresses that are not on the published list.
 
 ### Pricing
 

docs/cloud/high-availability/architecture-patterns.mdx

@@ -573,7 +573,7 @@ Here's how each component behaves during normal operation and after a failover:
 | Component | Normal operation | On failover |
 | --- | --- | --- |
 | **Workers** | Run in as many regions as you want — fleets don't have to match the Namespace's regions. Every fleet connects through the Namespace Endpoint. | Fleets in unaffected regions keep processing with no cold-start gap. Scale them up if needed to carry the full load. |
-| **Namespace** | One active replica; every other region holds a passive replica that receives replicated state. The Namespace Endpoint always routes to whichever region currently holds the active Namespace. | Temporal Cloud promotes a passive replica in another region to active. Every fleet follows automatically — no reconfiguration, nothing to bring up. |
+| **Namespace** | One active replica; every other region holds a passive replica that receives replicated state. The Namespace Endpoint always redirects via DNS to whichever region currently holds the active Namespace. | Temporal Cloud promotes a passive replica in another region to active. Every fleet follows automatically — no reconfiguration, nothing to bring up. |
 | **Workflow starters and Clients** | Run wherever convenient and connect through the Namespace Endpoint, like the Workers. | Automatically follow the Namespace Endpoint to the new active region, like the Workers. |
 | **Codec Servers and proxies** | Run in every region where Workers run. | Already running in every surviving region — no action needed. |
 | **Databases and queues** | Accessed from every Worker region, so you need a cross-region consistency story. | Promote the active region's copy, if needed, so the Workers there can read and write it. |

docs/cloud/high-availability/failovers/index.mdx

@@ -116,7 +116,7 @@ The failover process is the same whether it is triggered automatically by Tempor
    3. This hybrid strategy balances consistency and availability. During the switch, Workflow operations are briefly
       paused, and Temporal Cloud returns a retryable "Service unavailable" error to SDKs.
 
-4. **The Namespace Endpoint re-routes to the active region.** This DNS change can take a few minutes to fully propagate
+4. **The Namespace Endpoint redirects via DNS to the active region.** This change can take a few minutes to fully propagate
    to all Clients and Workers. If your application has an extremely demanding Recovery Time, you can eliminate this
    stage by connecting through a [Regional Endpoint](/cloud/high-availability/ha-connectivity#regional-endpoint) instead
    of the Namespace Endpoint.