feat(bridge): parallel message processing for IM channels

[lowmiaq-gmail]

Summary

• When bridge_parallel_tasks setting is true, messages arriving while a session is busy are dispatched to ephemeral worker sessions instead of being queued serially in a per-session Promise chain
• Worker sessions inherit provider, model, working directory, and mode from the parent binding
• Worker sessions do not overwrite channel_bindings — the primary chat→session mapping stays intact
• Backward compatible: when bridge_parallel_tasks is unset or false, behavior is unchanged (serial processing)

Problem

When users send multiple messages rapidly on Feishu/Telegram/Discord, each message was serialized via processWithSessionLock(). The second message had to wait for the first to complete before processing could begin, causing noticeable delays and queue notifications.

Solution

Added a busy-session check (activeTasks + sessionLocks) in the adapter loop. When a session is detected as busy:

1. createWorkerBinding() creates a new ephemeral session inheriting parent config
2. The message is dispatched to the worker session in parallel (fire-and-forget)
3. The main session continues processing its original message undisturbed

Files changed

• src/lib/bridge/bridge-manager.ts — parallel dispatch logic in runAdapterLoop(), handleMessage() accepts optional override binding
• src/lib/bridge/channel-router.ts — new createWorkerBinding() function

Test plan

• Enable bridge_parallel_tasks=true in settings
• Send 3+ messages rapidly on Feishu
• Verify all messages get concurrent responses without queue delay
• Verify no "⏳ in queue" notifications appear
• Verify original chat binding is not overwritten by worker sessions
• Verify worker sessions inherit correct provider/model from parent

🤖 Generated with Claude Code

[vercel]

Someone is attempting to deploy a commit to the op7418's projects Team on Vercel.

A member of the Team first needs to authorize it.