openclaw - 💡(How to fix) Fix Feature request: make group room-event steering configurable

Problem

When messages.queue.mode=steer is enabled, active-run steering is still hard-disabled for group room events. In the current runtime behavior, room events are treated as followups rather than injectable steering input because shouldSteer is gated on !isRoomEvent.

This is usually a safe default for ambient group/lurk behavior, but it blocks legitimate operator workflows where a group message should steer an already-running task. A concrete example is a time-sensitive auth/approval code posted in the same group thread while the agent is actively waiting for it.

Requested behavior

Please make group room-event steering optional/configurable instead of hard-disabled. For example:

• Keep the current behavior as the default.
• Add a setting such as messages.queue.allowRoomEventSteering or messages.queue.steerRoomEvents.
• Ideally allow per-channel or per-group override, since ambient public rooms and operator-owned task rooms have different safety expectations.
• When disabled, continue routing active group room events as followups/message-tool-only as today.
• When enabled and messages.queue.mode=steer, allow group room events to use the same active-run steering path as direct messages.

Why this matters

Group chats can be operational control rooms, not only ambient channels. A global hard block forces brittle workarounds outside the normal session/queue model. A config flag would preserve safe defaults while letting trusted deployments opt into steering for selected groups.