chore: bump aiohttp from 3.13.4 to 3.14.1

[dependabot]

Bumps aiohttp from 3.13.4 to 3.14.1.

Changelog

Sourced from aiohttp's changelog.

3.14.1 (2026-06-07)

Bug fixes

• Fixed a race condition in :py:class:~aiohttp.TCPConnector where closing the connector while a DNS resolution was in-flight could raise :py:exc:AttributeError instead of :py:exc:~aiohttp.ClientConnectionError -- by :user:goingforstudying-ctrl.

  Related issues and pull requests on GitHub: :issue:12497.

• Fixed CancelledError not closing a connection -- by :user:aiolibsbot.

  Related issues and pull requests on GitHub: :issue:12795.

• Tightened up some websocket parser checks -- by :user:Dreamsorcerer.

  Related issues and pull requests on GitHub: :issue:12817.

• Fixed :class:~aiohttp.CookieJar dropping the host-only flag of cookies when persisted with :meth:~aiohttp.CookieJar.save and reloaded with :meth:~aiohttp.CookieJar.load, so a cookie set without a Domain attribute is again scoped to the exact host that set it after a reload; the absolute expiration deadline is now persisted as well, so a reloaded cookie keeps its original lifetime instead of being rescheduled from the load time. :meth:~aiohttp.CookieJar.load now replaces the jar contents rather than merging onto prior state, and loaded cookies pass through the same acceptance rules as :meth:~aiohttp.CookieJar.update_cookies, so a cookie for an IP-address host is dropped when loaded into a jar created without unsafe=True -- by :user:bdraco.

  Related issues and pull requests on GitHub: :issue:12824.

• Scoped :class:~aiohttp.DigestAuthMiddleware credentials to the origin of the first request it handles, so a redirect to a different origin no longer triggers a digest response computed from the configured credentials; a challenge from another origin is only answered when that origin falls within a protection space advertised by the anchor origin through the RFC 7616 domain directive -- by :user:bdraco.

  Related issues and pull requests on GitHub: :issue:12825.

• Fixed the C HTTP parser not enforcing max_line_size on a request target or response reason phrase that is split across multiple reads; each fragment was checked on its own, so an accumulated line could exceed the limit without raising LineTooLong. The accumulated length is now checked, matching the pure-Python parser -- by :user:bdraco.

  Related issues and pull requests on GitHub:

... (truncated)

Commits

• 9c35d03 Release v3.14.1 (#12864)
• 38b956c [PR #12861/59684b5c backport][3.14] Revert "Drop list compression (#12857)" (...
• 8f31009 [PR #12857/69dff14d backport][3.14] Drop list compression (#12858)
• dfdfa9d [PR #12830/93a2b1c3 backport][3.14] Bound pipelined request queue per connect...
• 0e9cedd [PR #12827/ccf218ab backport][3.14] Numeric ipv4 resolver bypass (#12849)
• a762eda [PR #12831/1ac92dae backport][3.14] Payload close on disconnect (#12843)
• a329a7a [PR #12824/60b85e98 backport][3.14] Preserve host-only cookie scope across Co...
• 4f7480e [PR #12828/13b635d7 backport][3.14] Bounded unread compressed drain (#12845)
• 5ab61bb [PR #12826/36df6c13 backport][3.14] Enforce max_line_size on fragmented reque...
• 3912667 [3.14] Add test that env proxy auth is scoped to the redirect-selected proxy ...
• Additional commits viewable in compare view

[Allob]

@dependabot rebase