ExponentialBackoff overflows timedelta above attempt 46

`ExponentialBackoff.__call__` computes

```python
delay = min(self.base_delay * (self.factor**context.attempt), self.max_delay)
```

so the product is evaluated before `min()` clamps it. With the default shape (base delay 1 s, factor 2.0, max delay 1 h) the product exceeds the `timedelta` limit at attempt 47:

```
OverflowError: days=1628906115; must have magnitude <= 999999999
```

### Repro (threadmill 0.7.1)

```python
import datetime
from types import SimpleNamespace
from threadmill.retry import ExponentialBackoff

policy = ExponentialBackoff(
base_delay=datetime.timedelta(seconds=1),
max_delay=datetime.timedelta(hours=1),
factor=2.0,
max_retries=720,
)

def context(attempt):
error = SimpleNamespace(exception_class=ValueError)
return SimpleNamespace(attempt=attempt, task_result=SimpleNamespace(errors=[error]))

for attempt in range(1, 60):
try:
print(attempt, policy(context(attempt)))
except Exception as exc:
print(attempt, type(exc).__name__, exc)
break
```

Attempts 1 to 46 return a delay (2 s doubling to the 1 h cap at attempt 12), attempt 47 raises.

### Why it matters

`Executor.retry_delay` catches the exception, logs `Retry callback failed`, and returns `None`, so the backend acknowledges the result and the retry chain ends. The task looks like it exhausted its policy, but `max_retries` was never reached: a policy of 720 attempts really stops after 46 retries.

### Suggested fix

Clamp in seconds before building the `timedelta`, and derive the capped attempt count from `max_delay` so the exponential is never evaluated past the cap:

```python
seconds = min(
self.base_delay.total_seconds() * self.factor**context.attempt,
self.max_delay.total_seconds(),
)
return datetime.timedelta(seconds=seconds)
```

A plain `min()` on the two `timedelta` values does not help on its own, because the product still overflows before the comparison.

Found while bounding the spam scan retry budget in codingjoe/relay#230.

threadmill.retry.ExponentialBackoff.__call__ から始め、min() が適用される前にその遅延がどのように計算されるかを確認します。提供された試行ループで問題を再現し、その後 Executor.retry_delay を確認して、高い試行回数でも callback が失敗しなくなったことを確認します。max_retries までの試行が max_delay に制限されたままとなり、overflow で終了しなければ完了です。

索引モデルが issue の本文から書いたものです。