Redirect credential leakage across scheme/port in HTTP.jl

Summary

### Description

Redirect handling decided whether to retain credential-bearing headers (`Authorization`, `Cookie`, `Proxy-Authorization`, etc.) by comparing only the hostname, ignoring scheme and port. As a result an `https`→`http` downgrade or a same-host/different-port redirect was treated as same-origin and replayed credentials over plaintext or to a different service. Additionally, per-call `cookies=` cookies were captured once and re-appended on every hop even after the `Cookie` header was stripped, and the TLS verification host was pinned to the original host across redirects.

### Impact

Following an attacker-influenced redirect could disclose a client's credentials or cookies to a different origin (different scheme or port) than the one they were intended for, including over plaintext.

### Patches

Fixed in HTTP.jl v2.4.0. Sensitive-header retention now requires matching scheme and port (with default-port normalization) in addition to the existing host/subdomain check, cross-origin hops also clear the explicit `cookies=` vector so they are not re-attached, and the SNI/verification host is recomputed from the redirect target on every hop unless the caller explicitly pinned `server_name`.

Reported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.