feat(feishu): feishu-local-cli-agent-bridge-design

[GatewayJ]

• feishu local cli agent bridge

[RussellLuo]

This only looks up the current agent->Feishu participant mapping. If an agent used to run with participant A and this update removes the Feishu binding or rebinds it to participant B, EnsureAgent() will call StopAgent(a.ID) but this code can no longer recover participant A, so the old stream keeps running under the stale participant. Consider tracking the active participant ID per agent (or stopping the previous binding before applying the new one) so rebinding/removal tears down the old bridge reliably.

[RussellLuo]

This new multiCodexBridgeManager path feels a bit too heavy for cli/serve now.

At this point serve.go is no longer just wiring dependencies and deciding what to start. It also owns bridge orchestration details such as:

• combining multiple bridge managers
• deciding start/restore behavior
• coordinating Start / EnsureAgent / StopAgent / Close
• resolving channel-specific bindings like the Feishu participant ID
• repairing missing Codex sessions by stopping and restarting the agent runtime

That is bridge-domain logic, not just server bootstrap logic. Keeping it here makes serve.go the place that knows both runtime wiring and per-channel bridge behavior, which will get harder to maintain as more bridge types are added.

I think a cleaner split would be to keep only the top-level assembly in cli/serve and move the manager/orchestration layer into internal/channelbridge (for example internal/channelbridge/manager.go or a small subpackage there). Then serve.go would just build a channelbridge manager from its dependencies, while the bridge package owns:

• multiCodexBridgeManager
• the CSGClaw/Feishu manager implementations
• binding resolution helpers
• start/restore policy helpers

The only part I would keep watching during that move is the current ensureSession() behavior, because it reaches into agent lifecycle (svc.Stop / svc.Start). If this gets extracted, it would be cleaner to pass that capability in as an explicit dependency instead of letting channelbridge depend on broad agent.Service details directly.

So I do think this should be pushed down, but with the dependency boundary tightened at the same time; otherwise it is only moving code out of serve.go without really reducing coupling.