Define transport policy for authenticated provider endpoints

**What problem would this solve?**

Goose supports authenticated provider endpoints configured by URL. Some provider-specific and custom-provider paths can send reusable credentials and model traffic to an explicitly configured non-loopback `http://` endpoint. Requiring HTTPS everywhere would protect remote traffic, but Goose also supports local development servers where loopback HTTP may be necessary.

The policy is currently inconsistent across provider constructors and configuration surfaces. A URL accepted by one path may be rejected or constrained by another, and redirect behavior can further change the effective destination.

**What would a good outcome look like?**

Goose has one documented transport policy for authenticated provider endpoints. Remote credentials and model traffic are never sent over cleartext transport. Legitimate local development remains possible through a precisely defined exception, and every CLI, Desktop/ACP, declarative, and provider-specific constructor enforces the same rule before credentials are attached.

**Possible approaches**

- Require HTTPS for every non-loopback authenticated endpoint and permit HTTP only for verified loopback IPs/hostnames.
- Decide whether private-network HTTP is rejected, warned, or requires an explicit insecure override.
- Resolve hostnames and redirects without allowing the request to leave the originally authorized transport class or origin.
- Apply the decision centrally where possible, while adding provider-specific regression coverage for built-in endpoint overrides and declarative providers.
- Define migration/error messaging for existing remote HTTP configurations.

**Additional context**

The design should explicitly cover bearer tokens, custom authorization headers, prompt/history/tool-schema traffic, redirects, IPv4/IPv6 loopback, and hostname resolution. Implementation should wait until the issue reaches **Ready** on the Goose Issues board.

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

Look at provider constructors and configuration surfaces for authenticated endpoints. Identify where URLs are validated and where credentials are attached. The policy must be defined centrally and enforced before credentials are sent. Check for existing tests around endpoint validation and redirects to understand the current behavior.

Escrito por el modelo de indexación a partir del texto del issue.