fix(internal/conf): override config path with datadir via CLI flag

[mkitsdts]

Description / 描述

原先的读取配置文件逻辑：

通过命令行传入的datadir做conf的初始化，然后读取配置文件覆盖conf

修改后的逻辑：

配置文件覆盖conf之后，根据命令行传入的datadir做路径重写

Motivation and Context / 背景

issue #2268

How Has This Been Tested? / 测试

分别使用不传入datadir的命令和传入datadir的命令启动服务，正常运行

Checklist / 检查清单

• I have read the CONTRIBUTING document.
  我已阅读 CONTRIBUTING 文档。
• I have formatted my code with go fmt or prettier.
  我已使用 go fmt 或 prettier 格式化提交的代码。
• I have added appropriate labels to this PR (or mentioned needed labels in the description if lacking permissions).
  我已为此 PR 添加了适当的标签（如无权限或需要的标签不存在，请在描述中说明，管理员将后续处理）。
• I have requested review from relevant code authors using the "Request review" feature when applicable.
  我已在适当情况下使用"Request review"功能请求相关代码作者进行审查。
• I have updated the repository accordingly (If it’s needed).
  我已相应更新了相关仓库（若适用）。
  • OpenList-Frontend #XXXX
  • OpenList-Docs #XXXX

[pikachuren]

🙏 感谢 @mkitsdts 提交！
🤖 AI 自动审核声明：本评审报告由 AI 自动生成，当前使用 Claude Opus 5 模型进行分析。
⚠️ AI 分析结果仅供参考，可能存在误判或遗漏。如您发现任何问题或有不同意见，欢迎随时提出讨论和纠正。
⚠️ 重要提醒：即使 AI 评审认为代码质量良好且建议合并，最终是否合并仍需由项目维护者进行人工判定。项目维护者会综合考虑代码质量、项目规划、技术方向、团队资源等多方面因素做出决策。

🎯 结论

🔄 Request Changes — 解决了真实问题，但路径重写覆盖不全且存在一处逻辑反直觉的条件判断

📖 概要

fix(internal/conf): override config path with datadir via CLI flag · 修复命令行 --data 参数被配置文件覆盖的问题（#2268）。
核心改动：把 datadir 的路径推导移到配置文件加载之后执行，从而让 CLI 参数优先级高于配置文件。

🧭 整体方案

调整了「CLI 参数」与「配置文件」的生效顺序：原先先用 datadir 初始化默认值、再被配置文件整体覆盖，导致 CLI 参数失效；改为加载配置后再按 datadir 重写路径。优先级方向是对的（CLI > 配置文件 > 默认值），但重写时机的改变会让配置文件中显式设置的路径也被无条件覆盖，需要斟酌。

📊 变更统计

1 个文件（+11 / -0 行） | 功能 ⭐⭐⭐⭐ | 最小改动 ⭐⭐⭐⭐ | 前向兼容 ⭐⭐ | 方案设计 ⭐⭐⭐

🚨 关键问题

P0（阻塞合并）：无

P1（建议修复）：

• ⚠️ internal/bootstrap/config.go — if conf.Conf.DistDir != "" 这个条件的语义有点反直觉：只有当用户已经显式配置了 DistDir 时，才会把它改写成 <datadir>/dist；反之如果用户没配，DistDir 就保持为空、不受 datadir 影响。这意味着用户越是明确指定了自定义 dist 路径，越会被覆盖掉。请问这是刻意设计吗？直觉上似乎应该反过来（未配置时才用 datadir 推导）~
• ⚠️ 路径重写只覆盖了 DBFile / TempDir / BleveDir / Log.Name / DistDir 五项。配置结构中其他与路径相关的字段（如各类缓存目录、Scheme 下的证书路径等）不会跟随 datadir。请问是否考虑补全，或在文档中明确说明 --data 的作用范围？

P2（可选）：

• 💡 当 Log.Enable 为 false 时不改写 Log.Name。若用户后续在管理端开启日志，路径仍指向旧位置。是否考虑无条件改写路径、只让 Enable 控制是否真正写文件？
• 💡 建议补一条启动日志，输出最终生效的 datadir 与各路径，便于用户确认参数是否生效~

📂 逐文件分析

internal/bootstrap/config.go

改动意图：让 --data CLI 参数优先于配置文件生效。
代码逻辑：在 LoadConfig 之后，若 flags.DataDir != "" 则用 filepath.Join 重新推导五个路径字段。
问题分析：核心思路正确；主要问题是 DistDir 的条件判断方向可疑（P1）与路径覆盖不完整（P1）。
详细建议：DistDir 部分建议明确语义，例如仅在用户未显式配置时才由 datadir 推导：

if conf.Conf.DistDir == "" {
    conf.Conf.DistDir = filepath.Join(flags.DataDir, "dist")
}

✅ 待处理清单

• [P1] 确认并修正 DistDir 条件判断的语义方向
• [P1] 补全其余路径字段，或在文档中说明 --data 的覆盖范围
• [P2] 评估 Log.Enable 为 false 时是否也应改写日志路径
• [P2] 增加启动时的生效路径日志

🎯 结论：🔄 Request Changes — 优先级修复方向正确，但 DistDir 判断需澄清、覆盖范围需补全。