fix: avoid codebase-retrieval timeouts and release search DB handles

[wei500L]

变更摘要

这个 PR 主要解决两个问题：

1. codebase-retrieval 在已有索引仓库上仍然同步触发增量索引，导致查询容易超时
2. 检索链路中的 SQLite 句柄没有及时释放，容易表现为索引库被长期占用、看起来像“进程锁残留”

主要修改

1. 调整 codebase-retrieval 的索引策略

• 对首次使用、尚未建立索引的仓库，仍然保持同步建索引
• 对已经存在索引的仓库，查询优先直接使用现有索引返回结果
• 增量索引改为后台异步执行，避免把索引耗时绑定到查询主链路上
• 增加跨进程的后台索引请求标记，减少多个 MCP 进程重复拉起后台索引任务

2. 强化项目锁实现

• 为锁增加 owner token，避免不同进程误释放彼此的锁
• 为长时间索引任务增加心跳续期，避免锁在索引过程中被误判为失效
• 损坏锁文件和死进程锁可以自动回收
• 后台 index 在短超时下抢不到锁时会快速退出，不再长时间阻塞

3. 修复检索链路的资源释放问题

• SearchService 增加显式 close()
• ContextPacker 在打包完成后关闭 SQLite 连接
• GraphExpander 增加 close()，并改为每次请求创建独立实例
• handleCodebaseRetrieval() 在 finally 中统一释放检索阶段资源

行为变化

• 对“已有索引”的仓库，查询结果会优先基于当前索引返回
• 如果仓库刚发生变更，极短时间窗口内结果可能略旧，随后由后台增量索引收敛
• 这个取舍是为了避免查询请求被索引过程阻塞，优先解决超时问题

验证

已完成以下验证：

• pnpm build 通过
• 已建索引仓库上的 search 请求可以快速返回，不再被同步增量索引阻塞
• handleCodebaseRetrieval() 执行完成后，不再残留 index.db / index.db-wal / index.db-shm 句柄
• 损坏锁文件可以自动回收
• 锁心跳会刷新时间戳，并在任务结束后正确释放锁文件
• 第二个进程竞争同一把锁时，会在短超时内失败
• 持有项目锁时，后台 index 子进程会快速退出，不会并发写同一个索引库

风险说明

• 这是一次有意的行为调整：查询优先级高于增量索引实时性
• 当前仓库没有现成的自动化测试用例，这次主要依赖源码编译和实际进程级验证