lzf_0626
661b17c244
预警详情里的资金流水/持仓/登录记录、以及日报的四组预警都是"一次性取全量"。某个客户 的历史数据一旦异常膨胀，单次响应就能把内存和连接拖垮；登录记录此前更是连时间窗都 没有。 处理原则是"封顶但**不静默**"：详情证据每类最多 200 条、日报每组最多 5000 条，用 `limit + 1` 多取一行判断是否真被截断（只看"取满没取满"会把恰好等于上限的正常数据 误报成截断），被截断时： - 详情新增 `evidence_truncated: string[]`，列出被截断的证据类型； - 日报新增 `data_truncated: bool` —— 日报的 daily_alert_count 等数字直接来自行数， 静默截断等于给出一份看起来正常、实际少统计的日报，那比报错更难发现。 `scalars(...)` 统一用 `list(...)` 而不是 `.all()`，实现不再依赖 ScalarResult 的专有方法。 新增 tests/unit/repository/test_risk_repository_limits.py（3 例，用 literal_binds 编译 SQL，确保断言看到的是 201 而不只是"有 LIMIT"），并补日报与详情的标记用例； 风控文档 06 同步登记两个新字段与写接口的幂等要求。