fix: enhance MessageBus by added lock and extractions.

[StarsExpress]

Refs issue #438's 3rd point to adjust code_puppy/messaging/bus.py: MessageBus.

Part 1: add a lock for provide_response()

Originally, emit() has with self._lock: wrapping the code to add message into self._outgoing.

However, provide_response() didn't have it, so I let it have one as well — for wrapping the code to add command into self._incoming.

Part 2: refactor emit() and provide_response()

Same drop-oldest pattern duplicated in emit() and provide_response() - small DRY nit, extract _put_with_drop(queue, item).

A shared static method joins MessageBus now:

@staticmethod
def _put_item_into_queue(q: "queue.Queue[T]", item: T) -> None:
    """Put item into queue. If queue is full, use FIFO to drop oldest and retry."""

    try:
        q.put_nowait(item)

    except queue.Full:
        try:
            q.get_nowait()
            q.put_nowait(item)

        except queue.Empty:
            pass

How emit() calls _put_item_into_queue:

self._put_item_into_queue(self._outgoing, message)

How provide_response calls _put_item_into_queue:

self._put_item_into_queue(self._incoming, command)

Part 3: TypeVar("T") shared at module level

Since several methods need TypeVar("T") for type safety, the following definition moves to a place between imports and the start of MessageBus:

T = TypeVar("T") # Auto-detect variable type.

[mpfaffenberger]

Locks make me very nervous.

[StarsExpress]

Locks make me very nervous.

Haha I hear you — locks are usually where bugs go to hide. Plus, we all like freedom a lot 😅

This morning I ran some commands, and have these interesting but also tricky results:
messaging/bus.py::provide_response() — the part I added the new lock — has no production callers.

1. Command tracing

rg -n "from code_puppy.messaging.bus import|from \.\.messaging\.bus import|from \.bus import" code_puppy/ --type py gives this:

2. PyCharm's Find Usages

Checked on MessageBus.provide_response as well: only referenced within messaging/ itself and corresponding tests.

Observations

So MessageBus.provide_response is architecturally present but currently has zero production consumers.

This PR #875 is more like making sure the foundation is solid for whenever/if something actually gets wired up to it.