Define secure transport policy for credentialed MCP HTTP extensions

**What problem would this solve?**
Desktop and deep-link extension setup can configure a Streamable HTTP MCP endpoint together with request headers. A remote cleartext `http://` endpoint would carry authorization credentials and MCP traffic without transport protection. At the same time, local MCP services may legitimately use loopback HTTP or a Unix socket. We need one backend-enforced transport policy that every configuration ingress applies consistently.

**What would a good outcome look like?**
Require HTTPS for credential-bearing TCP endpoints unless an explicitly defined local transport exception applies. Define exactly which loopback names/address ranges and Unix-socket forms are allowed, how redirects are revalidated, and whether credentials are stripped when origin or scheme changes. Desktop must explain the policy before persistence, while the backend remains authoritative for deep links, imported configuration, and other clients.

The verification plan should cover: remote HTTP with Authorization/custom secret headers; HTTPS; localhost, IPv4 and IPv6 loopback; hostname rebinding/normalization; Unix-socket configuration; redirects to a weaker scheme or different origin; and direct backend configuration that bypasses the modal.

**Possible approaches**
- Reject credential-bearing remote HTTP centrally in extension configuration/runtime validation.
- Permit only numeric loopback and Unix-socket transports under a narrowly documented exception.
- Require an explicit per-extension unsafe opt-in for any cleartext TCP transport and never send reusable credentials there.

Public issue #11500 is related redirect hardening; this issue defines the initial transport and credential policy across all configuration ingresses.

**Additional context**
The shared extension runtime serves both agent-loop implementations, so enforcement and tests must cover both paths.

- [x] I have verified this does not duplicate an existing feature request

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).

L’issue concerne la sécurisation des extensions HTTP de MCP. Commencez par examiner la configuration des extensions et le code de validation à l’exécution, probablement dans le runtime partagé des extensions. Cherchez où les endpoints HTTP sont configurés avec des headers. Comprenez la gestion actuelle du transport et l’endroit où les identifiants sont ajoutés. Les tests doivent couvrir le HTTP distant avec des identifiants, HTTPS, les adresses de loopback, les sockets Unix et les redirections.

Rédigé par le modèle d'indexation à partir du texte de l'issue.