[jeremydmiller]

What changed

• New DoThenRetry(action, maxAttempts = 3, description = "Do then retry") on IFailureActions / PolicyExpression, so it is available on global policies (opts.OnException<T>()), on a handler chain (chain.OnException<T>()), and after Then.
• New internal DoThenRetryContinuationSource / DoThenRetryContinuation. The continuation implements both:
  • IContinuation: run the action, then lifecycle.RetryExecutionNowAsync() (queued path, with the same retry tracing as RetryInlineContinuation)
  • IInlineContinuation: run the action, then return InvokeResult.TryAgain (IMessageBus.InvokeAsync() path)
• maxAttempts counts the original attempt, like Requeue(maxAttempts): it adds maxAttempts - 1 slots. Once they run out, the normal exhausted behaviour applies, the same as RetryTimes(): dead letter when queued, exception thrown to the InvokeAsync() caller. maxAttempts must be 2..25.
• RetryExecutionNowAsync() inline behaviour is unchanged.
• Docs: new "Do this, then retry" section in docs/guide/handlers/error-handling.md, sourced from the test's sample_do_then_retry region.

Why

A CustomAction that does recovery work and then retries can't know whether it is running inline or queued, so the same lambda either throws (RetryExecutionNowAsync() inline) or doesn't retry. Users had to write their own dual continuation plus an attempts check.

Tests run locally (net9.0, Release)

• CoreTests --filter-class "*do_then_retry*": 6/6 passed (queued recover, inline recover, queued exhausted -> dead letter, inline exhausted -> throws, rule description/attempt slots with Then, argument validation)
• CoreTests --filter-namespace "CoreTests.ErrorHandling*": 249/249 passed
• src/Wolverine and CoreTests build with 0 warnings / 0 errors

Closes #5068

🤖 Generated with Claude Code

https://claude.ai/code/session_01DCggXgxnG3EBXoR9rrq37U