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).