TLS session cache case-folds CA paths and bypasses the active trust profile

How it was found

curl 8.21.0 case-folds the entire TLS session-cache peer key, so two distinct CA files whose Unix paths differ only by case can share a TLS session ticket.

At lib/vtls/vtls_scache.c:723, curl_strequal() compares keys that include case-sensitive CA, CRL, and issuer paths, even though docs/internals/TLS-SESSIONS.md says lookup uses exactly the same peer key.

Run the attached poc-casefolded-scache.py: each of its two vulnerable passes first trusts Trust.pem, switches to an unrelated trust.pem, logs SSL reusing session, sends Authorization: Bearer VICTIM_CANARY, receives two HTTP 200 responses, and exits 0.

cert controls: good_rc=0 bad_rc=2
run1 case-only bad CA: rc=0 reused=True canary_sent=True http_200=2
run2 case-only bad CA: rc=0 reused=True canary_sent=True http_200=2
control different-name bad CA: rc=60 reused=False canary_sent=False http_200=1

The control uses the same unrelated CA under Different.pem; curl performs a full certificate handshake, exits 60, and never sends the canary, while changing the known-key lookup to strcmp() produces the same safe result.

Current master 2687751471c04e07a9c5da78338569d97aff7fd4 is still affected; this is a session-ticket-cache regression distinct from CVE-2021-22924's live connection-cache bug because the vulnerable cache was added later by fa0ccd9f, and I used AI to assist the audit and report while personally rerunning and checking every claim.

Impact

An application that reuses a multi handle or shared TLS session cache across per-transfer CA profiles can send credentials or request data to a server that the active CA profile explicitly does not trust.