fix(deps): pin certifi to 2026.10.19 everywhere to release v4.8
Cherry-pick of commit 7b32394c1854a557eb9efb23424331ec0758dd98 to release/v4.8 branch.
Summary by cubic
Pins certifi to 2026.10.19 across all backend requirements files and uv.lock so v4.8 can be released with a consistent, secure certificate bundle.
Closes #16365
I changed no files because PR #16337 on main already pins certifi to 2026.10.19, and the workflow applies that fix to this branch. The advisory (PYSEC-2026-4320 / GHSA-6q48-6c7w-9gw2) is about certifi before 2026.10.19 still trusting the emSign ECC Root CA - G3 root, whose intermediate CA keys were compromised. Anyone holding one of those keys who can also intercept the network traffic could read or change TLS connections made by clients that trust the certifi bundle. The root pyproject.toml has no certifi pin; certifi 2025.11.12 is in uv.lock only because other packages need it, among them requests==2.33.0, httpx==0.28.1, urllib3==2.8.0, the OpenAI, LiteLLM, Cohere and Google clients, and many connector SDKs. These libraries use certifi's CA bundle by default for every outbound HTTPS call, such as connector syncs, LLM provider calls and web fetches. That means the weak trust store is used in production. I only had a file-read tool, so I could not search the whole tree for an override of REQUESTS_CA_BUNDLE/SSL_CERT_FILE, but nothing I read suggests one, so I'm treating Onyx as affected. Exploiting it is hard, since the attacker needs both a compromised key and a position on the network path.