feat: retry policies with exponential backoff and exception filtering

[thomhurst]

Closes #4890. Adds BackoffMs, BackoffMultiplier, RetryOnExceptionTypes to [Retry].

[claude]

Code Review

Overall this is a clean, well-structured feature addition. The API design is intuitive and the documentation is thorough. Two issues found:

---

Issue 1: Public API snapshot tests not updated (CLAUDE.md Rule 2 violation)

The PR adds several new public API members to TUnit.Core but does not update the .verified.txt snapshot files in TUnit.PublicAPI/. These files currently show the old RetryAttribute API surface without the new properties, and the snapshot tests will fail on CI.

New public members missing from all four .verified.txt files:

• RetryAttribute.BackoffMs
• RetryAttribute.BackoffMultiplier
• RetryAttribute.RetryOnExceptionTypes
• DiscoveredTestContext.SetRetryBackoff(int, double)
• TestDetails.RetryBackoffMs
• TestDetails.RetryBackoffMultiplier
• ITestConfiguration.RetryBackoffMs
• ITestConfiguration.RetryBackoffMultiplier

Per CLAUDE.md: "Changes to source generator output or public APIs require running snapshot tests. Commit .verified.txt files."

Fix: Run the snapshot tests, review the generated .received.txt files, and accept them:

# From TUnit.Core.SourceGenerator.Tests or the relevant test project:
# Linux/macOS:
for f in *.received.txt; do mv "$f" "${f%.received.txt}.verified.txt"; done
# Then commit the updated .verified.txt files

---

Issue 2: Integer overflow in exponential backoff delay calculation

In RetryHelper.cs:

var delayMs = (int)(backoffMs * Math.Pow(multiplier, attempt));

if (delayMs > 0)
{
    await Task.Delay(delayMs, testContext.CancellationToken).ConfigureAwait(false);
}

Math.Pow returns a double. When backoffMs * Math.Pow(multiplier, attempt) exceeds int.MaxValue (2,147,483,647), the (int) cast in an unchecked context (C# default) produces an implementation-defined value — typically int.MinValue (-2,147,483,648) on .NET x64.

With BackoffMs = 1000 and the default BackoffMultiplier = 2.0, this happens at attempt 22 (1000 × 2²² = 4,194,304,000 > int.MaxValue). At that point delayMs becomes negative, the if (delayMs > 0) guard evaluates to false, and exponential backoff silently stops working — retries continue with no delay instead of increasing delays.

While attempt 22 is extreme, smaller BackoffMs values with a higher multiplier (e.g., BackoffMs = 500, BackoffMultiplier = 3.0) overflow much sooner.

Recommended fix — cap the computed delay to avoid the overflow:

private static async Task ApplyBackoffDelay(TestContext testContext, int attempt)
{
    var backoffMs = testContext.Metadata.TestDetails.RetryBackoffMs;

    if (backoffMs <= 0)
    {
        return;
    }

    var multiplier = testContext.Metadata.TestDetails.RetryBackoffMultiplier;
    var rawDelayMs = backoffMs * Math.Pow(multiplier, attempt);
    
    // Cap to int.MaxValue to avoid undefined behavior from unchecked cast
    var delayMs = (int)Math.Min(rawDelayMs, int.MaxValue);

    if (delayMs > 0)
    {
        await Task.Delay(delayMs, testContext.CancellationToken).ConfigureAwait(false);
    }
}

Or use TimeSpan.FromMilliseconds which accepts a double directly, avoiding the cast entirely:

var delay = TimeSpan.FromMilliseconds(rawDelayMs);
await Task.Delay(delay, testContext.CancellationToken).ConfigureAwait(false);

(TimeSpan.FromMilliseconds accepts a double and handles large values gracefully, and Task.Delay(TimeSpan, CancellationToken) accepts TimeSpan up to ~24.8 days.)