fix(os): avoid recursive signal cancellation lock

[stephenlclarke]

Summary

Avoid recursively acquiring AsyncSignalHandler's state mutex during cancellation.

cancel() previously called AsyncStream.Continuation.finish() while holding the lock. Finishing invokes the continuation's onTermination callback, which calls cancel() again and can deadlock on the same non-recursive mutex.

Drain the continuations and dispatch sources under the lock, clear the shared state, then finish and cancel those resources after releasing the lock. This keeps repeated cancellation idempotent while removing the recursive lock path.

Testing

swift test --filter AsyncSignalHandlerTests

Result: 1 focused regression passed. It creates multiple signal streams, cancels them, verifies both finish, and then cancels again.

Compatibility

No public API changes. Signal sources and streams are still cancelled by the same call; only the lock boundary changes.