Fix AsyncWorkQueue fork lock deadlock

[ADovgalyuk]

Summary

Avoid acquiring the global fork read lock while holding AsyncWorkQueue::m_mutex.

Root cause

WorkerThreadMain() previously called aeThreadOnline() while holding m_mutex. This allowed the following cycle during BGSAVE/BGREWRITEAOF:

1. worker A holds m_mutex and waits for the fork read lock;
2. the fork operation waits for the fork write lock;
3. worker B already holds the fork read lock and waits for m_mutex.

The cycle prevents every participant from making progress.

Changes

• Use the condition-variable predicate form to handle wakeups and shutdown under m_mutex.
• Release m_mutex before aeThreadOnline().
• Reacquire m_mutex only after the worker owns the fork read lock.
• Preserve the existing task execution and pending async-write processing flow.

The remaining lock order is consistently fork lock -> queue mutex; a worker blocked on the fork lock no longer prevents another worker from completing and releasing its read lock.

Validation

• Final branch diff contains only src/AsyncWorkQueue.cpp.
• Repository CI will build KeyDB and run the configured unit-test set.
• Recommended runtime validation: concurrent async commands with repeated BGSAVE/BGREWRITEAOF cycles.

Related upstream report: Snapchat#883.