fix: relax boto3/botocore upper-bound pin to avoid dependency conflicts

[nsleigh]

Summary

• The <1.38 ceiling on boto3/botocore was stale and started conflicting with other Home Assistant integrations (e.g. LLM Vision) that require a newer boto3 with no upper bound, causing HA's requirements installer to fail setup entirely with RequirementsNotFound for any integration depending on this package.
• The AWS Cognito IdP auth calls this library relies on (InitiateAuth/RespondToAuthChallenge) are stable across boto3/botocore versions, so there's no need to cap it.

Test plan

• CI passes (unit tests unaffected by dependency version bump)
• Confirm pip install resolves cleanly alongside a newer boto3-pinning integration (e.g. LLM Vision)

🤖 Generated with Claude Code

[KJonline]

Have you tested home assistant with this update in place. Ive seen issues before when trying to upgrade the boot libray

[nsleigh]

Yes, been running it for a couple of months.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.96%. Comparing base (1f7c92f) to head (499b995).

Additional details and impacted files

@@           Coverage Diff           @@
##              dev     #153   +/-   ##
=======================================
  Coverage   99.96%   99.96%           
=======================================
  Files          30       30           
  Lines        2571     2571           
  Branches      297      297           
=======================================
  Hits         2570     2570           
  Partials        1        1           

Flag	Coverage Δ
unittests	99.96% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

Verdict: blocking issue — this reintroduces a previously-fixed regression.

Bugs / blocking

• pyproject.toml: dropping the <1.38 ceiling on boto3/botocore undoes PR Cap boto3/botocore to <1.38 for aiobotocore compatibility #136 (which fixed Unpinned boto3/botocore upgrades break aiobotocore consumers (e.g. Home Assistant) #135). That fix capped the range specifically so pip stays inside what aiobotocore 2.21.x accepts; without it, Home Assistant envs that also use aiobotocore (Cloudflare R2, IDrive e2, Nice G.O. integrations, per the original bug report) can again fail to set up after the Hive config flow resolves boto3/botocore to the latest release. This PR trades that regression for fixing a different real conflict (an integration requiring boto3 with no upper bound → RequirementsNotFound). Both symptoms are genuine; simply removing the cap isn't a fix, it just moves the breakage to different users. See inline comment for suggested next steps (confirm current aiobotocore compatibility and set an appropriate ceiling, or otherwise reconcile the two constraints).

Other findings

None — this is a one-line dependency change with no code, test, or public-API impact.

Not reviewed

N/A — the diff is limited to pyproject.toml.

[KJonline]

Following up on the automated review above: its "blocking" verdict is out of date, and this change is correct.

The <1.38 cap from #136 was right in May, when Home Assistant shipped aiobotocore 2.21.x (botocore 1.37.x only). #135 itself said to raise it once HA moved to aiobotocore 3.x, and HA has now done that. Current HA (2026.9.x stable and dev) has:

• aiobotocore==3.7.0 in requirements_all.txt, which requires botocore>=1.42.90,<1.43.1
• a hard pin of boto3==1.42.97 / botocore==1.42.97 in homeassistant/package_constraints.txt, applied to every integration's requirement install. It exists specifically to stop a runtime install dragging botocore out of aiobotocore's range (the Unpinned boto3/botocore upgrades break aiobotocore consumers (e.g. Home Assistant) #135 problem), now handled centrally by HA.

So the <1.38 cap (published in 2.0.0b1) can't be satisfied alongside HA's constraint, which is the RequirementsNotFound failure described here. Removing it is safe: inside HA the constraint holds boto3/botocore at a compatible version, and outside HA an open upper bound is normal for a library.

Thanks @nsleigh, and for confirming it has been running fine for a couple of months.

(Posted with Claude Code; the review bot will also be updated to check HA's dependency constraints on dependency changes.)