feat: 为全部 39 个 Rust 源文件添加系统性中文注释

为整个项目添加了详尽的中文文档注释，覆盖所有模块：

入口与架构:
- main.rs — 架构图、数据流、4 个关键设计决策
- cli.rs — 所有 CLI 子命令中文化
- Cargo.toml — 每个依赖的作用说明
- channel/mod.rs — 渠道标识设计意图

核心守护进程与消息队列:
- daemon.rs — 三消费者架构图、审批流
- queue/* — 公平轮转算法、路由调度架构

LLM 层:
- types.rs — Role/Message/ToolCall 等每个字段含义
- provider.rs — Provider trait 设计 + SSE 解析
- conversation.rs — 工具循环流程图、摘要机制
- deepseek.rs — API 请求格式

上下文管理:
- context/types.rs — ChatSession 消息生命周期
- context/builder.rs — Token 预算管理策略
- context/tools.rs — MemoryStore 双写策略

工具系统:
- tools/mod.rs — 两层元工具架构图
- tools/approval.rs — 审批流程
- tools/definitions.rs — 声明式工具三要素
- tools/subprocess.rs — 执行流程 + 缓存策略

数据库与状态:
- db/* — 5 张表用途、回退策略
- state.rs — 文件存储回退方案
- scheduler.rs — SKIP LOCKED 防重复

已废弃模块:
- ipc.rs — 旧 UDS 协议
- worker.rs — 旧 vs 新架构对比

src/daemon.rs

@@ -1,7 +1,43 @@
-//! Daemon — 常驻进程
+//! ## Daemon —— 常驻守护进程（核心循环）
 //!
-//! 持有 WeChat 长连接 + 数据库。使用消息队列架构将消息处理分解为
-//! LLM / Tool / Send 三个消费者（tokio task），通过 QueueRunner 路由。
+//! 这是整个项目的核心入口循环。它的职责：
+//!
+//! 1. **持有 WeChat 长连接** — 通过 `WeChatClient` 长轮询接收微信消息
+//! 2. **持有数据库连接** — 可选 PostgreSQL，回退到文件存储
+//! 3. **管理审批流程** — `ApprovalManager` 处理高风险工具的确认码审批
+//! 4. **管理长期记忆** — `MemoryStore` 提供按用户隔离的记忆读写
+//!
+//! ### 消息处理架构（三消费者 + 公平队列）
+//!
+//! daemon 将消息处理拆分为 3 个独立的 tokio async task（消费者），
+//! 通过 `MessageQueue` + `QueueRunner` 做公平轮转路由：
+//!
+//! ```text
+//! receive_messages → enqueue PipelineMessage
+//!       │
+//!       ▼
+//!  ┌──────────────────┐
+//!  │   MessageQueue   │ ← 公平轮转（A1, B1, A2, A3）
+//!  └────────┬─────────┘
+//!           │ dequeue
+//!           ▼
+//!  ┌──────────────────┐
+//!  │   QueueRunner    │ ← 按 MessageKind 路由
+//!  └──┬──────┬──────┬─┘
+//!     │      │      │
+//!     ▼      ▼      ▼
+//!  LLM     Tool    Send
+//!  Cons.   Cons.   Cons.
+//! ```
+//!
+//! - **LLM Consumer** — 调用 DeepSeek API 做对话 + 工具循环
+//! - **Tool Consumer** — 执行内置工具，高风险工具先走审批
+//! - **Send Consumer** — 将 LLM 回复通过 WeChat API 发回给用户
+//!
+//! ### 与旧架构的关系
+//!
+//! 旧架构使用 `daemon + worker` 分离模式（UDS IPC），worker 已废弃。
+//! 当前是统一的单进程 tokio task 架构。
 
 use crate::channel::ChannelId;
 use crate::context::MemoryStore;
@@ -19,17 +55,29 @@ use tokio::sync::Mutex;
 use tracing::{error, info, warn};
 use uuid::Uuid;
 
-/// Daemon 上下文 —— 消费者共享的所有状态
+/// ## Daemon 上下文 —— 消费者之间共享的全部状态
+///
+/// 这个结构体被所有三个消费者（LLM / Tool / Send）通过 `Arc` 共享访问。
+/// 每个字段都只读（或内部有锁），所以不需要额外的 `Mutex` 包装。
 struct DaemonCtx {
+    /// 数据库句柄（可选，没有时走文件存储）
     db: Option<Arc<Database>>,
+    /// WeChat API 客户端（内部用 Arc<Mutex> 保护 token/updates_buf）
     client: WeChatClient,
+    /// 本机器人的微信账号 ID
     account_id: String,
+    /// 审批管理器 —— 处理高风险工具的用户确认码流程
     approval: Arc<ApprovalManager>,
+    /// 长期记忆管理器 —— 按用户隔离的记忆读写
     memory_store: Arc<MemoryStore>,
+    /// 注册给 LLM 的工具列表（JSON 格式，符合 function calling 规范）
     tools_list: Vec<serde_json::Value>,
+    /// 系统提示词，覆盖默认值
     system_prompt: String,
+    /// 使用的模型名称（如 `deepseek-v4-flash`）
     model: String,
-    /// 待审批: user_id → (原始文本, context_token, 工具名, tool_args, 创建时间)
+    /// 待审批的上下文：`user_id → (原始文本, context_token, 工具名, 工具参数, 创建时间)`
+    /// 用户在聊天中发送确认码时，从这里面查找匹配项
     approval_ctx: Mutex<HashMap<String, (String, Option<String>, String, String, Instant)>>,
 }