refactor(async): improve retry() input validation

[tomas-zijdemans]

Switched to using delay() for timeout handling.

Input handling:

• Uses RangeError instead of TypeError for invalid options
• Validates maxAttempts is a positive integer
• Validates multiplier is a finite number >= 1
• Validates jitter is between 0 and 1 (was only checking > 1)
• Adds NaN checks for maxTimeout, minTimeout, and jitter

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.18%. Comparing base (13e5527) to head (124f405).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6922   +/-   ##
=======================================
  Coverage   94.17%   94.18%           
=======================================
  Files         584      584           
  Lines       43087    43102   +15     
  Branches     6875     6883    +8     
=======================================
+ Hits        40578    40596   +18     
+ Misses       2457     2455    -2     
+ Partials       52       51    -1     

☔ View full report in Codecov by Sentry.
📢 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.

[kt3k]

We have the policy of accepting a new feature to stable APIs as unstable feature first. See https://github.com/denoland/std/blob/main/.github/CONTRIBUTING.md#new-features-in-stable-packages-version--100

Can you move feature addition part of this change to a different PR, targeting unstable_retry.ts?

[tomas-zijdemans]

We have the policy of accepting a new feature to stable APIs as unstable feature first. See https://github.com/denoland/std/blob/main/.github/CONTRIBUTING.md#new-features-in-stable-packages-version--100

Can you move feature addition part of this change to a different PR, targeting unstable_retry.ts?

Sorry, I should have considered that!

I've reverted the new feature, while still keeping delay() instead of setTimeout. I hope this is acceptable (it allows retry to handle very large timeouts correctly)

[kt3k]

LGTM