[Bug] kimi-datasource plugin worker pool blocks all sessions on timeout

标题

[Bug] kimi-datasource 插件 worker 池阻塞导致多会话同时卡死

正文

环境

• kimi CLI 版本：最新
• 操作系统：Linux
• 插件：kimi-datasource（yahoo_finance）

复现步骤

1. 同时运行 3 个 kimi 会话（如 stock、music、task_todo_app），均使用 kimi-datasource 插件的 yahoo_finance API
2. 其中一个会话密集调用 get_stock_info（如港股 1208.HK、02099.HK 等），部分请求超时 30 秒
3. 超时发生后，其他两个会话的所有模型（k3、deepseek）均无响应，任何 get_stock_info 调用均挂起
4. ps aux 显示多个 kimi-code 进程（PID 不同）共享同一个 /kimi-code/plugins/managed/kimi-datasource 工作目录

实际行为

• 共享 datasource worker 池的会话全部阻塞，不只是超时的那个会话
• CPU 98% 空闲，内存充足（9.5GB 可用），排除资源耗尽
• kill 掉卡住的旧会话后，其他会话立即恢复正常

预期行为

一个会话的插件调用超时不应影响其他无关会话。

推测根因

kimi-datasource 的 worker 进程在多个会话间共享。某个 worker 处理超时请求后未正确归还连接池，导致后续所有会话的请求排队等待一个永不释放的 worker。

建议修复方向

• 每个会话使用独立的插件 worker 实例，或
• worker 池加入超时强制回收机制（超过 N 秒自动 kill），或
• 请求级超时不应影响 worker 的可再分配状态

<!--This is a translation content dividing line, the content below is generated by machine, please do not modify the content below-->
---
## Title

[Bug] The kimi-datasource plug-in worker pool is blocked, causing multiple sessions to freeze at the same time.

## Text

### Environment

- kimi CLI version: latest
- Operating system: Linux
- Plugin: kimi-datasource (yahoo_finance)

### Reproduction steps

1. Run 3 kimi sessions (such as stock, music, task_todo_app) simultaneously, all using the `yahoo_finance` API of the `kimi-datasource` plugin
2. One of the sessions intensively calls `get_stock_info` (such as Hong Kong stocks `1208.HK`, `02099.HK`, etc.), and some requests time out for 30 seconds.
3. After the timeout occurs, **all models** (k3, deepseek) of the other two sessions are unresponsive and any `get_stock_info` calls hang
4. `ps aux` shows that multiple `kimi-code` processes (different PIDs) share the same `/kimi-code/plugins/managed/kimi-datasource` working directory

### Actual behavior

- All sessions sharing the datasource worker pool are blocked, not just the session that timed out.
- CPU 98% idle, sufficient memory (9.5GB available), excluding resource exhaustion
- After `kill` drops the stuck old session, other sessions will return to normal immediately.

### Expected behavior

Plugin call timeouts for one session should not affect other unrelated sessions.

### Speculate the root cause

The worker processes of `kimi-datasource` are shared among multiple sessions. A worker failed to return the connection pool correctly after processing a timeout request, causing all subsequent session requests to be queued and waiting for a worker that would never be released.

### Suggested repair direction

- use a separate plugin worker instance per session, or
- Add a timeout forced recycling mechanism to the worker pool (automatic kill after N seconds), or
- Request-level timeouts should not affect a worker's reassignable status

Reproduce the issue with three kimi sessions using the kimi-datasource plugin's yahoo_finance API and repeated get_stock_info calls, then inspect the shared /kimi-code/plugins/managed/kimi-datasource worker state. Trace what happens after the 30-second timeout and verify that one session's stalled worker no longer blocks other sessions.