using the cfs to the updated extract

[jack-wang-176]

Pull Request

描述 (Description)

本 PR 主要为项目引入了基于 Redis 的多租户公平调度器（模拟linux内核对进程分配cpu资源），解决了高频提交任务可能导致的 Asynq 底层队列饿死其他租户的问题。同时将在container中创建的context改为在main中创建并传递，对于desktop的入口在Wails OnShutdown hook协程中添加cancel产生信号，对于server的入口在协程外创建context并通过调整进程间通信来保留原来针对多次 ctrl+c 的强制退出和单次的等待资源清理后退出

核心变更内容：

1. CFS 公平调度器实现：引入 TenantFairScheduler 接口，基于 Redis ZSET (cfs:vruntime) 和 List (cfs:tenant:{tenantID}) 实现 vruntime 算力追踪，保障租户公平性。
2. DTO 抽象与 Asynq Option 透传：引入 interfaces.CfsTaskOptions 和 interfaces.CfsTaskWrapper，解耦业务层与 Asynq 指针，确保 TaskID、MaxRetry、Queue 等动态配置在经过 Redis 序列化/反序列化后能被精准还原。
3. Knowledge 业务层适配：将 knowledge.go 与 new_knowledge.go 中所有直连 asynq.NewTask 的逻辑重构为调用 CFS 调度器，并封装了相应的 Cost 算力预估函数（如 estimateFAQImportTaskCost）。
4. DI 容器注入：在 BuildContainer 中将 CFS 调度器注册到 dig 容器，并关联其后台轮询大循环。
5. 优雅停机重构 (Graceful Shutdown)：统一 main.go 中的全局 Context ，严格规范关闭顺序（释放 Listener -> 等待 HTTP 排空 -> 关闭后台 CFS 大循环 -> 执行 resourceCleaner 清理数据库/Redis 连接），防止产生僵尸进程或断连 Panic。

变更类型 (Type of Change)

• 🐛 Bug 修复 (Bug fix)
• ✨ 新功能 (New feature)
• 🎨 代码重构 (Code refactoring)

影响范围 (Scope)

• 后端 API (Backend API)
• 其他 (Other): 核心调度器、依赖注入容器 (DIG)、主程序生命周期与优雅停机 (Graceful Shutdown)

测试 (Testing)

• 手动测试 (Manual testing)

测试步骤 (Test Steps)

1. 启动服务，确保 Redis 连接正常，触发多个租户的并发后台任务（如 FAQ 导入、文档解析）。
2. 观察 Redis 中的 cfs:vruntime ZSET 分数变动以及 cfs:tenant:{tenantID} List，验证新租户进入时的 vruntime 补偿机制是否生效，调度器是否按预期公平拉取任务。
3. 在 FAQ 导入等依赖 TaskID 的场景下，验证前端或进度查询 API 是否能正常获取基于指定 ID 的任务进度（证明 Option 透传成功）。
4. 向运行中的服务端发送 SIGINT (Ctrl+C) 信号，观察终端日志，验证 HTTP 服务器是否先停止接收请求，后台 CFS 调度器是否跳出循环，最后再执行 DB/Redis 资源清理，确保全程无 connection refused 相关的 Panic。

检查清单 (Checklist)

• 代码遵循项目的编码规范
• 已进行自我代码审查
• 代码变更已添加适当的注释
• 变更不会产生新的警告
• 已添加测试用例证明修复有效或功能正常

相关 Issue

无

截图/录屏 (Screenshots/Recordings)

数据库迁移 (Database Migration)

• 需要数据库迁移
• 不需要数据库迁移

配置变更 (Configuration Changes)

无新增配置项。复用现有的 REDIS_ADDR 判断，当存在 Redis 环境时自动启用 CFS 调度器，否则降级为同步执行器。

其他信息 (Additional Information)

目前对于文件类型和文件大小的权重计算只是通过个人经验，并没有相关数据支撑，后续可以针对这一点进行优化