Infinite Busy-Wait Loop in handleTypingEvent Freezes Application

The handleTypingEvent function in packages/api/src/EmbeddedChatApi.ts contains a Denial of Service (DoS) vulnerability due to a busy-wait loop.

The code uses a synchronous while(typingHandlerLock) {} loop to implement a lock mechanism for managing typing status updates. In JavaScript's single-threaded event loop environment, this pattern is dangerous. If an exception occurs while the lock is held (set to 1) and the lock is not explicitly reset in a finally block or error handler, the lock remains held forever.

Any subsequent call to handleTypingEvent will enter the while loop and never exit, because the loop blocks the main thread, preventing any asynchronous callbacks (like setTimeout) or other code from running to release the lock. This causes the entire application process or browser tab to freeze with 100% CPU usage.

Steps to reproduce:

1. Instantiate the EmbeddedChatApi.
2. Trigger handleTypingEvent in a way that causes an error after the lock is acquired (typingHandlerLock = 1) but before it is released.
3. Trigger handleTypingEvent a second time with any arguments.

Expected behavior:

The application should handle errors gracefully and ensure that locks are always released (e.g., using try...finally). Synchronization shouldn't block the main thread; it should use asynchronous patterns like Promises or a task queue if ordering is strictly required.

Actual behavior:

The application freezes indefinitely on the second call. The node process or browser tab becomes unresponsive and must be force-killed.

Start in packages/api/src/EmbeddedChatApi.ts and inspect handleTypingEvent, especially how typingHandlerLock is acquired and released. Reproduce the failure by triggering an error after acquisition, then call the handler again and observe the freeze. Done means errors cannot leave the lock permanently held and a second call no longer blocks the event loop indefinitely.