Define authenticated transport policy for remote extension allowlists

**What problem would this solve?**

Remote extension allowlists are an administrator policy input, but Goose currently accepts any configured URL and follows redirects without defining an authenticated-transport requirement. Existing deployments may rely on plaintext HTTP, especially for local services, so changing this needs an explicit compatibility policy.

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

Remote allowlist content has a documented transport-authentication rule that is enforced for the initial URL and every redirect. Administrators get a clear error for disallowed configurations and a narrowly defined migration path where needed.

**Possible approaches**

- Require HTTPS for all remote allowlists and reject downgrade redirects.
- Permit plaintext HTTP only for loopback addresses.
- Offer an explicit insecure compatibility override with prominent diagnostics and documentation.

The decision should cover redirects, local certificate deployments, startup failure behavior, and existing managed installations.

**Additional context**

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

Tìm đoạn mã tải các allowlist của extension từ xa, có thể nằm trong một mô-đun cấu hình hoặc bảo mật. Kiểm tra cách các URL được phân giải và các chuyển hướng được xử lý. Kết quả cần là một policy được xác định và thực thi tại thời điểm tải, kèm các thông báo lỗi rõ ràng cho những cấu hình không tuân thủ. Việc kiểm thử sẽ bao gồm mô phỏng các scheme URL và kịch bản chuyển hướng khác nhau.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.