Cookie jar accepts `Secure/__Host-/__Secure-` cookies from non-secure origins in HTTP.jl

Summary

### Description

`setcookies!` stored every parsed `Set-Cookie` after only checking that the response scheme was http or https, with no protection symmetric to the read path (`shouldsend`, which already withholds `Secure` cookies from non-secure requests). A plaintext (http) origin could therefore plant a `Secure` cookie, plant a `__Secure-`/`__Host-`-prefixed cookie, or overwrite/delete (via `Max-Age=-1`) an existing `Secure` cookie set over https, enabling cookie fixation against hosts that mix http and https.

### Impact

A network attacker or malicious http origin could set, overwrite, or delete security-sensitive cookies in the client's cookie jar, enabling cookie fixation.

### Patches

Fixed in HTTP.jl v2.4.0. Per RFC 6265bis, `setcookies!` now drops any `Secure` cookie arriving over a non-secure scheme, enforces the `__Secure-` and `__Host-` name prefixes (evaluated ASCII case-insensitively on the raw attributes), and refuses to overwrite or delete an existing `Secure` cookie of the same domain;path;name identity from a non-secure origin. Behavior over https is unchanged.

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