refactor(database): 将数据库初始化逻辑统一整合到 database 包

[jvhuaiying]

• 新增 app/database/init.py，整合建表、种子数据和基线计算为 init_database()
• 将 scripts/seed_data.py 和 scripts/compute_baseline.py 迁移到 app/database/
• 删除 scripts/init_db.py，建表逻辑已合并到 database 包
• 种子数据和基线计算增加幂等性检查，仅在空表时执行
• main.py 启动时调用 init_database() 替代内联建表代码
• 使用 pathlib.Path 替代 os.path 处理路径
• 简化 CI 流程和部署脚本中的数据库初始化步骤

[FlashingChen]

整体方向是好的，但考虑到这个项目的体量和目前的阶段，我个人觉得这个重构带来的收益不大，反而引入了风险。

路径变更未说明
DB_PATH 和 local_memory.py 的 _DATA_ROOT 从 backend/data/ 移到了 {项目根}/data/。这是一个行为变更，PR 描述里完全没有提及。如果服务器上现有数据在 backend/data/ 下，部署后启动会找不到，属于静默 breaking change。

重构的必要性存疑
原来的三个脚本各自职责清晰，CREATE TABLE IF NOT EXISTS 多处写一遍在这个体量的项目里完全无害。__init__.py 把 100+ 行建表 SQL、种子数据、基线计算全揉在一起，再加上函数内 late import 避免循环依赖，反而比原来的方案更难一眼看清。

半途的 pathlib 迁移
local_memory.py 里 _DATA_ROOT 改成了 Path，但下面的 WORKSPACE_ROOT 还在用 os.path.join，混搭风格不一致。

建议
这个项目目前更看重简单稳定，如果确实有数据库初始化上的痛点，可以先讨论清楚再动手。不然倾向于关掉这个 PR，保持现有方案。

[jvhuaiying]

这个pr只是一个过渡性内容，把数据库内容全部移入database目录下是为下一步引入SQLModel做准备，另外根据后期设想，为了出于整体可维护性的考量，包括根目录下的data目录在内，全部用于存储数据文件的data目录应该整体移入backend/data目录下，根目录下的data目录后期是需要移除的内容，现阶段对数据目录的修改确实存在问题，所以我更倾向于保持数据库部分代码的修改，并修正路径的问题

[FlashingChen]

理解，如果这个 PR 是为后续引入 SQLModel 做铺垫，那把数据库相关逻辑收进 app/database/ 这个方向是可以接受的，不一定需要关掉。

不过现在这个 PR 还差几个点，建议补完后再合：

1. 数据库路径保持不变
   现在 DB_PATH 从原来的 backend/data/baseline.db 变成了根目录下的 data/baseline.db，这个会导致线上已有数据读不到。这个路径需要保持原来的 backend/data/，不要在这个 PR 里迁移数据目录。

2. local_memory.py 的数据目录也不要改
   现在 _DATA_ROOT 也跟着变成了根目录 data/，这同样是行为变更。既然后续如果要调整数据目录，应该单独开 PR 做迁移，这里先保持现状。

3. make data 保留实际作用
   现在 make data 只 echo 一句话，等于把原来的本地初始化入口废掉了。建议改成调用新的 init_database(DB_PATH)，让开发者还是可以用 make data 初始化数据库。

4. 保留手动重算 seed / baseline 的入口
   现在 seed_data.py 和 baseline.py 迁到 app/database/ 后，原来的 CLI 入口没了，而且 baseline_stats 非空时就直接 return。启动时幂等是对的，但本地开发有时需要重新 seed 或重新计算 baseline，建议保留一个明确入口，比如 make data-refresh 或脚本参数。

5. 文件结构可以再拆一下
   __init__.py 里现在放了 100 多行建表 SQL，后面如果要接 SQLModel，建议把 schema 初始化拆到单独的 schema.py，__init__.py 只暴露 init_database() 这种入口函数。

总结：我认可 app/database/ 这个方向，但这个 PR 目前还不完整。路径兼容、make data、手动重算入口这几个补上后，再合会稳很多。