`wait_for`

There is no mechanism for waiting on a specific future event that matches a condition. Every feature that requires listening for a follow-up event, a confirmation reply, an expected reaction, the next message from a specific user, must wire up and tear down its own event listener manually. The planned [Dialog](#92) feature would need to solve this too, and doing it twice would produce two diverging implementations.

The idea is to add `bot.wait_for(event_type, check=..., timeout=...)` which suspends the caller until a matching event arrives. It would register a one-shot waiter internally, resolve it when the condition passes, and cancel it when the timeout expires. Dialog's `ctx.ask` would then be a thin wrapper over this rather than its own mechanism.

**Proposed API**
```python
# Wait for any message in the same room from the same sender
message = await bot.wait_for(
"on_message",
check=lambda room, event: event.sender == ctx.sender and room.room_id == ctx.room.room_id,
timeout=30.0,
)

# Wait for a specific reaction on a message
reaction = await bot.wait_for(
"on_react",
check=lambda room, event: event.reacted_to_id == msg.event_id,
timeout=60.0,
)
```

The implementation sits in `_on_matrix_event` / `_dispatch_matrix_event` in `bot.py`. A `dict[str, list[asyncio.Future]]` of pending waiters keyed by event name would work cleanly alongside the existing `_event_handlers`. Each waiter is an `asyncio.Future` paired with its check callable; when an event fires, the bot walks the waiter list, resolves any future whose check passes, and removes it. Timeout is handled by `asyncio.wait_for` on the caller side. The main edge case is concurrent waiters for the same event type (e.g. two dialogs running in parallel in different rooms), the list must not be mutated while being iterated, so a copy-on-iterate or deferred-removal strategy is needed.