Match the check the backend now performs

Two statements the section made are no longer true. Switching a record from one
provider to another re-checks it: the credential was accepted by one vendor and
the record now points at a different one. And a Bedrock record pointed at
somewhere other than an AWS runtime host is no longer wholly exempt — the
credential still goes unverified, but the URL is resolved on its own account,
since the listing comes from a host that cannot vouch for it.

src/pages/agent-network/providers.mdx

@@ -79,14 +79,17 @@ still in it, and the message names which of the two is at fault: the credential
 rejected, or the upstream URL could not be reached or does not answer a model listing. Fix
 the field it names and save again.
 
-On an existing provider, the check runs only when you change the **Upstream URL** or the
-**API key** — renaming a provider, editing model rows or changing prices saves without
-asking the vendor anything. Two consequences worth knowing:
+On an existing provider, the check runs only when you change the **Upstream URL**, the
+**API key**, or the **Provider** the record is connected to — renaming a provider, editing
+model rows or changing prices saves without asking the vendor anything. Three consequences
+worth knowing:
 
 - **Changing only the URL tests it against the stored credential.** The key never returns to
   your browser, so there is nothing else it could be tested with.
 - **A rejected key never replaces a working one.** If you paste a new key and the vendor
   refuses it, the provider keeps running on the old one.
+- **Switching the provider re-checks the credential you already stored.** It was accepted by
+  one vendor; the record now points at another, which has never seen it.
 
 **Which providers are checked.** The same four that can list their models: **OpenAI**,
 **Anthropic**, **Amazon Bedrock** and **Google Vertex AI**. Everything else saves without a
@@ -96,7 +99,9 @@ check, because there is no listing to ask for or no way to reach it:
   listing NetBird can ask for.
 - A Bedrock provider pointed at a proxy or a self-hosted endpoint rather than an AWS runtime
   host, because the control plane that serves the listing is derived from that URL and
-  cannot be worked out from an address AWS does not own.
+  cannot be worked out from an address AWS does not own. The credential goes unverified, but
+  the URL does not: Bedrock lists from a different host than it serves requests on, so the
+  one you entered is resolved on its own, and one that does not exist is refused.
 - Any upstream on a private address. Your agents reach it through the tunnel, but NetBird's
   management service has no route to it, so there is nothing it can ask.