perf: 历史图表的查询走独立的只读连接，不再挡住 agent 上报

[stqfdyr]

历史图表的查询改走一条只读连接，扫描再长也不会让 agent 上报和面板请求排队。

• 打开数据库时另开一条只读连接，/api/nodes/{id}/metrics 的资源、延迟、探测名称三个查询都走它。WAL 下它读的同时写连接照常提交
• 每次查询包在一个读事务里，水位线和它两侧的行来自同一个快照，与原来独占写连接时的结果一致
• 图表请求接连不断时只读连接一直持着快照，自动 checkpoint 无法重置 WAL。取读连接时 WAL 超过 4 MiB 就先在写连接上做一次 TRUNCATE checkpoint；不等待其他读者，导出备份进行中也不会占住写连接
• 导出备份改用同一个只读连接的打开方式
• 只读连接先于写连接关闭，hub 正常停机后库仍是单个文件，不留 -wal
• :memory: 开不了第二条连接，测试库仍走写连接
• 历史闸门仍是 4 个，扫描改在只读连接上排队，闸门决定的是图表最长等多久

测试

• cargo fmt --check、cargo clippy --all-targets -- -D warnings、cargo test（132 个）通过；scripts/e2e.sh 配 agent 1.1.0 通过
• 新测试持住写连接时读历史，必须在 5 秒内读完并读到已提交的数据，改回走写连接时它超时失败；另一个测试读过历史后关库，断言不留 -wal，两条连接的声明顺序换回去时它失败
• 新测试 4 路接连读历史、同时写入 2 万次，断言 WAL 不超过 16 MiB；去掉 checkpoint 时 WAL 涨到 85 MB 而失败
• release 版造库实测（21 个节点、7 天明细，其中一个节点 8 个 10 秒探测，共 48 万条探测记录）：4 个并发反复拉这个节点的 7 天延迟窗口，同时每 50 ms 请求一次走写连接的 /api/me，中位 1120 ms → 1.8 ms，最慢 1893 ms → 9.2 ms
• 同一个库上 4 路持续读 7 天窗口、每秒约 100 次提交：不做 checkpoint 时 WAL 20 秒涨到 20 MB 且不回落，加上后最高 4.5 MiB；写入延迟 p99 2.8 ms，无读压时为 3.5 ms
• 单次 7 天延迟窗口与改动前持平：4 个 60 秒探测约 90 ms，8 个 10 秒探测约 490 ms；8 个请求同时到达时 4 个 200、4 个 503
• 读压下压缩数据库 382 ms 完成，WAL 归零；正常停机后数据库目录只剩库文件