fix: Honor explicit timeout timedelta larger than timeout_max

[vdusek]

An explicit per-call timeout timedelta larger than timeout_max (default 360 s) was silently clamped to timeout_max on every attempt, contradicting the documented behavior "A timedelta overrides it for this call". For example, dataset.get_items_as_bytes(timeout=timedelta(minutes=30)) ran every attempt with a 360 s timeout, causing repeated impit.TimeoutException and failing the call despite the explicit 30-minute request.

Root cause: _compute_timeout used min(resolved * 2**(attempt-1), timeout_max), so min() shrank the resolved base timeout to timeout_max even on attempt 1, before any exponential growth. The fix caps growth at max(timeout_max, resolved) instead, so the base timeout is never shrunk below itself while retry growth stays bounded.

✍️ Drafted by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.66%. Comparing base (c1bffc6) to head (2ecbeea).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #962      +/-   ##
==========================================
+ Coverage   94.64%   94.66%   +0.01%     
==========================================
  Files          58       58              
  Lines        5263     5263              
==========================================
+ Hits         4981     4982       +1     
+ Misses        282      281       -1     

Flag	Coverage Δ
integration	92.60% <100.00%> (+0.30%)	⬆️
unit	83.94% <100.00%> (ø)

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

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Pijukatel]

Can you please verify in the API code that a timeout larger than 360 s has any meaning?

If there is some hard-coded or implementation limit on the API side, it makes no sense to lift the limit in the client.

(But a warning might be good in those cases)