[x-dc-coder]

PR：fix(repowiki): repoWiki_query 读取路径被二次拼接 basePath

动机

存储路径为相对值（上游 .env.example 默认 REPOWIKI_STORAGE_PATH=./.lumina/repowiki）时，MCP repoWiki_query 对任何页面都报：

open .lumina/repowiki/.lumina/repowiki/versions/<id>/wiki/overview.mdx: no such file or directory

.lumina/repowiki/ 前缀被拼了两次，Agent 侧无法读取任何已生成的 Wiki。

根因

readWikiPage 把 GetWikiPath() 的产物（已经包含 basePath 前缀）直接传给 SanitizePath，
而 SanitizePath 的契约为 basePath 相对路径（函数注释第 3 条：「相对路径拼接到 basePath 之下」），
对相对输入会再执行 filepath.Join(s.basePath, ...)，产出 {basePath}/{basePath}/versions/...。

两个原因导致此前不易察觉：

• 绝对路径配置（REPOWIKI_STORAGE_PATH=/abs/...）下 filepath.IsAbs 短路二次拼接，不触发；
• 网页 Reader（wiki_reader.go）读页面不经过 SanitizePath，一直正常，只有 MCP 查询走这条路。

行为变化

• 相对路径配置：repoWiki_query 从「恒失败」变为正常返回页面内容。
• 绝对路径配置：行为不变（filepath.Rel 转相对后再经 SanitizePath 拼回同一路径）。
• 不破坏 API、MCP 工具名与存储格式。

验证

• 新增回归测试 TestRepoWikiLogic_QueryWiki_RelativeStoragePath（internal/logic/repowiki_logic_test.go）：
  相对 basePath 下 QueryWiki 读取页面。未修复时精确复现 {basePath}/{basePath}/... 的
  no such file or directory，修复后通过。
• go test ./... 全绿；go vet ./... 无告警；gofmt 无差异。

备注

修复选择了调用方侧（readWikiPage 转相对路径后再校验），保持 SanitizePath 的既有契约不动；
如维护者更倾向让 SanitizePath 兼容已含前缀的输入，也愿意按该方向调整。

[xiaolfeng]

Code review

未发现问题（LGTM）。已完成代码缺陷、历史上下文与 CLAUDE.md / AGENTS.md 规范核查：

1. 根因与修复核验：GetWikiPath 产物已含 basePath 前缀，直接传入按相对路径契约工作的 SanitizePath 会在 REPOWIKI_STORAGE_PATH 为相对路径（如默认 ./.lumina/repowiki）时触发二次拼接。通过 WikiStorageService.BasePath() 与 filepath.Rel(l.svc.storage.BasePath(), wikiPath) 先还原为相对 basePath 的路径再交由 SanitizePath 校验，兼顾相对与绝对存储路径。
2. 安全边界：前置 isWithinDir(wikiPath, page) 跨版本目录隔离与 SanitizePath 存储根防逃逸双重校验保持完整。
3. 回归测试：TestRepoWikiLogic_QueryWiki_RelativeStoragePath 已覆盖相对路径配置场景，go vet 与 go test -race 全部通过。