wait_for_status_update_async only works for one waiter at a time #44

_register_answer overwrites whatever is already under that key:

def _register_answer(self, answer_id: str) -> None:
    with self.answer_events_lock:
        self.answer_events[answer_id] = asyncio.Event()

That's fine for command answers, since each one has its own counter as key. But "status" is a fixed key, and STATUS is a broadcast message — several callers may want to wait for the next one at the same time. wait_for_status_update_async registers that same key every time, and wait_for_kinematics_ready_async calls it in a loop.

With two waiters, one of two things happens:

A registers event E1 and captures it, then B registers E2 and replaces it in the dict. The receive thread only sets the dict entry, so nobody ever sets E1 and A waits until its timeout — with timeout=None that's 24 hours.
Both capture E2. Both wake up, and both run del self.answer_events[message_id], so the second one gets a KeyError.

This is easy to hit, e.g. with asyncio.gather over two helpers that each wait for a status update, or when user code watches the state while wait_for_kinematics_ready_async is running.

There's already a mechanism that seems meant for this: status_callback is called from _parse_message for every STATUS message, but nothing in the library ever assigns it. If wait_for_status_update_async used that path instead — as a list of listeners, so the public status_callback stays free for applications — each waiter could have its own event and "status" wouldn't need to be in answer_events at all.