[dipeshrayg]

Summary

• Update the hashed production and development locks from aiohttp 3.14.3 to 3.14.4. This fixes CVE-2026-111063, CVE-2026-111064, CVE-2026-111065, CVE-2026-111066, CVE-2026-111748, CVE-2026-111749, CVE-2026-111750 and GHSA-2g87-pp6c-29x5.
• Update certifi 2026.6.17 to 2026.10.19 for PYSEC-2026-4320. certifi is a direct pin, so requirements.in changes as well; aiohttp is transitive, so only the lock files change for it.
• Every other dependency version is unchanged. requirements-lock.txt is untouched.

Relationship to other PRs

• fix(deps): patch multidict and Werkzeug vulnerabilities #392 patches multidict and Werkzeug. This PR does not touch those two packages, so the two PRs edit different pins and should merge in either order. SCA (pip-audit) on this PR stays red until fix(deps): patch multidict and Werkzeug vulnerabilities #392 lands, because those two advisories are still on dev. Once both are merged, nothing is left unpatched (see Verification).
• build(deps): bump the pip group across 1 directory with 2 updates #399 (Dependabot) proposes the same aiohttp bump and is failing CI. This PR covers its aiohttp part with regenerated hashes, but not its Werkzeug part, which fix(deps): patch multidict and Werkzeug vulnerabilities #392 covers. build(deps): bump the pip group across 1 directory with 2 updates #399 can probably be closed once these two merge; I have not touched it.

Verification

• Auditing dev's current requirements.txt with pip-audit shows 11 advisories: 8 for aiohttp, 1 for certifi, 1 for multidict, 1 for werkzeug. With this PR applied only the multidict and werkzeug ones remain. With this PR and fix(deps): patch multidict and Werkzeug vulnerabilities #392 combined, both requirements.txt and requirements-dev.txt audit as "No known vulnerabilities found".
• The diff is two hunks per lock file (the aiohttp and certifi blocks), and every changed line is either one of the two pins or a --hash=sha256: line.
• Full test suite against the new versions: 1536 passed, 1 failed. The failure is test_every_rule_has_its_own_executable_playbook, which checks Unix file-mode bits that a Windows checkout does not have; it passes on Linux CI. ruff check, ruff format --check and validate_mapping_pack.py pass.

How the locks were generated, and what I could not run

docs/dependency-locking.md says to regenerate with scripts/lock_dependencies.py on CPython 3.11 on Linux. I did not have 3.11 on Linux. I ran the same pip-compile commands as that script (same flags, same order, tools pinned by hash from requirements-lock.txt) on Linux (WSL Ubuntu 24.04) under CPython 3.12.3. To check that this was a safe substitute I first regenerated dev's three lock files with no input changes; all three came out byte-for-byte identical to the committed files. I could not run scripts/lock_dependencies.py --check itself because it refuses anything other than 3.11 on Linux, so the CI lock-consistency check is the authoritative confirmation here. If it reports drift, I will regenerate with 3.11.

I have not tested anything against live Azure; this change only touches dependency pins.