feat: add turn admission hook

[Gezi-lzq]

Motivation

ChannelManager currently schedules each inbound channel message as a new turn immediately. The default concurrent behavior is simple, but plugins do not have a hook to decide whether the next message for an already-active session should be processed now, queued, dropped, or offered to the running turn as steering input.

This PR adds an optional scheduling decision point while keeping the default behavior unchanged.

Design

Add a new first-result hook:

admit_message(session_id, message, turn) -> AdmitDecision | None

None means no decision; if every implementation returns None, Bub keeps the current default concurrent scheduling behavior.

AdmitDecision supports four actions:

• PROCESS: schedule immediately
• DROP: discard explicitly
• WAIT: process after the active turn finishes
• STEER: enqueue as per-session steering input for model hooks to consume via state["_runtime_steering"]

Undrained steering messages are promoted to the front of the pending queue when the active turn finishes, preserving FIFO order.

Scope

• admission only applies to the ChannelManager path; direct process_inbound() calls are unaffected
• Bub does not apply size, count, rate, or capacity limits to admission queues; plugins that need such policy can return DROP explicitly
• steering is currently per-session, not per-turn
• builtin agent steering consumption and whether turn cancellation should become a framework capability can be discussed separately

Verification

• uv run pytest -q
• uv run ruff check .
• uv run mypy src

[frostming]

Not complete reviewed yet. I think we should first resolve the fundamental design choice.

[frostming]

Looks like too many abstraction layers, consider uniting SteeringHandle and SteeringBuffer

[Gezi-lzq]

The split between SteeringHandle and SteeringBuffer is probably premature for this PR.

This PR currently treats steering as session-scoped, but there is an unresolved design question around whether steering should eventually target a session, a specific active turn, or a forked tape/turn branch. If that becomes first-class later, a public handle over a different internal routing/storage model might make sense.

For now, since the PR only implements session-scoped steering, I agree we can collapse this into one simpler type and avoid the extra abstraction.

[frostming]

Is it better to implement this as a method of Channel?

Because steering is highly related to channels, each channel should be able to define its own steering logic. The current approach only takes the first implemented hook.

[Gezi-lzq]

I see admit_message as more than channel-side input handling. Some decisions, especially STEER, only become meaningful when they are paired with a run_model implementation that knows how to consume steering input. If the active model hook never drains the steering queue, a channel-level STEER decision cannot actually steer the running turn.