[ISSUE-0058] 长期改进 3 连击¶

之前 ISSUE-0056 / 0054 留作"下轮再做"的 3 个低风险长期改进。本轮一并解决。（useDataSource hook 大重构第 4 项工程量大风险高，独立 ISSUE-0059+ 再做）

#1 getListByTaskId 100k → 200k + truncated 信号¶

病灶：src/utils/jsstore/search-data.ts:105 硬编码 limit: 100000。 - task > 10w 数据时拉前 10w → JS filter taskId → 后段漏 - 调用方传入的 pageSize 参数只控制 slice，不影响总拉取

修： 1. 提常量 export const TASK_SCAN_LIMIT = 200_000（覆盖 99% 任务规模） 2. 返回值加 truncated?: boolean 字段（>= TASK_SCAN_LIMIT 时为 true） 3. UI（local-data-view banner）后续可读 truncated 提示用户

代价：200k 行 select 约 ~ 0.3-1MB 内存（每行 ~ 1-5KB），可接受。

#2 client mode delete optimistic update¶

病灶：v0.10.74 #2 修了 delete 后调 onRequestRefreshSnapshot，但 DataView 的 refreshRows 是异步 useRequest.refresh — 拉到新 50k 需 ~ 100-1000ms。期间 client mode useMemo 仍用 stale rowsSnapshot 派生 → 看到已删的行 ≤ 1s。

修：optimistic UI 模式： 1. 新 state optimisticDeletedIds: Set<string> 2. deleteRun.onBefore 把 selectKeys 加进 set 3. clientPaged useMemo 过滤掉 set 内的 ids（立即删除视觉效果） 4. useEffect([rowsSnapshot]) 监听到 rowsSnapshot 不含这些 ids 后清空 set 5. deleteRun.onError 失败时清空 set（防 UI 少行但 DB 还在）

边缘： - selectOption='current' 时 selectKeys 就是确切删的 ids → 全 cover - selectOption='all'/'front' 时 selectKeys 只是当前页 ids → 当前页立即对齐，但其他页（用户翻不到的）仍要等 polling

#3 keyword 一致性：delete/export 走 client 同款 JS filter¶

病灶： - client mode UI clientPaged 用 (name|domain|category).includes(k) (OR) - server delete/export 走 jsstore where → exViewFilterToQuery(..., keyword, ...) → jsstore like 单字段 - 同一 UI 状态（keyword='apple'）下"看到的范围"vs"删/导的范围"不一致

修：src/api/search.ts:resolveTargetRows： 1. needsClientFilter = !!taskId || !!hasEmailOnly || !!keyword（加 keyword） 2. needsClientFilter 路径里：baseQuery = exViewFilterToQuery(filters, '', logic) — 去掉 keyword 走 jsstore where 3. 在 scanned 上 JS filter keyword（与 client 一致 OR 三字段 includes） 4. taskId 路径已经走 getListByTaskId 内部的同款 client keyword filter（line 110-118） — 无需改

效果：用户 keyword='apple' 看 10 行 → 选全部 → 删恰好这 10 行（不再差几行）。

性能：50k JS keyword filter ~ 30-50ms，比 jsstore like 慢一点点，但用户主动操作可接受。

未做（v0.10.79+ 大重构）¶

#4 useDataSource hook 重构 — agent 元洞察推荐：

"把 saveParams / dataRefresh / allCount 这些跨路径状态抽成单一信号源"

工程量 ~ 半天，回归测试覆盖面大（LocalDataView 是 22w 用户依赖最重的页面）。等再出 ISSUE-0059/0060 等需要时再做。当前 3 连击已经把数据安全和体验问题修到位。

audit_grep¶

- pattern: "selectByQuery.*limit:\\s*100000"
  description: "task scan 上限改用 TASK_SCAN_LIMIT 常量（200k），不要硬编码"