Add a whole-operation Policy.OverallTimeout

Today the only way to bound how long a Do call can run in total is the caller's own ctx deadline, set independently, or MaxAttempts combined with a worst-case backoff calculation the caller has to do by hand every time a policy changes. For a request-handling path with its own SLA (e.g. an HTTP handler that must respond within N seconds regardless of how many attempts a downstream needs), that mismatch is a real risk: a policy tuned for "retry aggressively" can end up running far longer in the worst case than any caller actually intended, holding a connection/goroutine open the whole time. A Policy-level overall deadline makes "this whole retry operation, no matter how it's configured, will never run past N" an explicit, self-contained guarantee that travels with the policy itself.

A field, OverallTimeout time.Duration, has been added as scaffolding in pkg/retry/policy.go ("bounds the total wall-clock time of an entire Do/DoWithResult call... independent of whatever deadline the caller's ctx already carries"). Nothing enforces it. A policy with a large MaxAttempts and a long BaseDelay/MaxDelay combination can run for as long as the arithmetic works out to, regardless of OverallTimeout.

policy := retry.Policy{MaxAttempts: 30, BaseDelay: 50 * time.Millisecond, Multiplier: 1, OverallTimeout: 150 * time.Millisecond} result := retry.Do(context.Background(), alwaysFailingFn, policy) // got: Do runs for ~1.458s (the full MaxAttempts * BaseDelay worst case), ignoring OverallTimeout entirely // want: Do returns at approximately the 150ms OverallTimeout mark

MaxAttempts alone doesn't bound wall-clock time in any way that's easy to reason about at a call site far from where the policy was defined -- someone tuning BaseDelay/Multiplier/MaxDelay for better backoff characteristics can accidentally blow past a latency budget nobody re-checked. An explicit OverallTimeout makes the bound a first-class, self-documenting part of the policy.

DoWithResult already respects ctx cancellation via ctx.Err() checks and the backoff-sleep select. context.WithTimeout composes cleanly with an existing context -- wrapping the caller's ctx with one more layer near the top of DoWithResult (only when policy.OverallTimeout > 0) should make every existing cancellation check "just work" for the new deadline too, with no changes needed to the loop body itself. Don't forget to call the returned cancel function.