Fix lock-order inversion deadlock in AsyncCurrentValue

[bok-]

📒 Description

The previous implementation resumed pending continuations inside wrappedValue's didSet, which executed within the mutex lock. This created a lock-order inversion when a task cancellation raced a concurrent update: the update thread held the mutex and called continuation.resume() (which internally acquires Swift's task status lock), while the cancelling thread held the task status lock and entered the onCancel: handler (which attempted to acquire the mutex). Neither thread could proceed.

The fix moves continuation resumption outside the mutex. The update method now atomically captures the updated value, bumped generation, and pending continuations inside the lock, then resumes continuations after releasing it. No continuation can miss a generation because the registration and extraction of continuations happen within the same lock closure — any continuation arriving after the extraction will see the already-bumped generation and return immediately.

Fixes #153.

🗳 Test Plan

A regression test that reproduces the original race over 100,000 iterations is included.

✅ Checklist

• I've added at least one test that validates that my change is working, if appropriate
• I've followed the code style of the rest of the project
• I've read the Contribution Guidelines
• I've updated the documentation if necessary

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[gqbit]

Beautiful - thank you @bok-!