Feature Request: Update vendored mbedtls

Prerequisites

• I am running the latest code. Mention the version if possible as well.
• I carefully followed the README.md.
• I searched using keywords relevant to my issue to make sure that I am creating a new issue that is not already open (or closed).
• I reviewed the Discussions, and have a new and useful enhancement to share.

Feature Description

PR #1011 reuses the Mbed TLS already vendored in third_party/mbedtls. That tree is cosmopolitan fork of Mbed TLS 2.26.0 (March 2021) — byte-identical to what llamafile ≤ 0.9.3 shipped and used for HTTPS.

Proposed follow-up: vendor vanilla Mbed TLS 3.6 LTS (security-fix-only, supported until at least March 2027) to replace the frozen fork. The cpp-httplib backend already supports 3.x natively (CPPHTTPLIB_MBEDTLS_V3 path), so the integration in this PR should carry over: swap the vendored tree, port config.h/BUILD.mk, keep the sslroot bundle and getrandom entropy glue; the include/mbedtls/ shims become unnecessary (3.x uses that layout natively). This also brings TLS 1.3 and, more importantly, replaces an unmaintained fork with an upstream LTS branch whose point releases can be diffed and bumped routinely.

Before doing this, check feasibility and, more importantly, the changes in cosmo's fork so we can evaluate whether they need to be carried over for this version.

Motivation

2.26.0 predates every upstream security advisory since March 2021, and the 2.x line is EOL (2.28 LTS support ended early 2025), so there is no upstream branch to backport from anymore. Fixes only land in 3.6 LTS and 4.x.

Quick security assessment ran with Fable: the fork's local trimming (no PSA, no DTLS, no TLS 1.3, legacy ciphers removed) makes many post-2021 advisories inapplicable. However, its README.cosmo notes it deliberately removed the Lucky Thirteen CBC timing protections for performance, while CBC ciphersuites and static-RSA key exchange remain enabled — so RSA/CBC timing-side-channel advisories plausibly apply to code we compile. In practice the client path negotiates ECDHE+AEAD with HF/CDNs, so exposure there is modest; the optional --ssl-cert-file TLS server accepts arbitrary clients and raises the stakes more.

Possible Implementation

No response