修复 PR 232 后台表查询评审问题

后台筛选要求 eq/ne 必须提供标量 value，缺失时返回 400。

统一表单和标题区查询入口的筛选完整性校验。

行内交互控件键盘事件不再冒泡触发行详情。

空字段详情复制给出明确失败反馈。

补充后端与后台页面回归测试。

同步更新后台表查询契约说明与运维文档。

docs/【开发运维】本地开发验证与生产运维-2026-05-15.md

@@ -903,7 +903,7 @@ SELECT * FROM profile_recharge_product_config ORDER BY sort_order ASC;
 
 后台通用表查询的“每页条数”不是筛选前的 SQL 截断量。API Server 通过单次 `SELECT * ... LIMIT 50001` 读取哨兵行，最多保留前 50,000 条候选；关键词 / 字段条件过滤、所选列的完整候选集稳定排序和 1-based `page` 分页都基于这一次 SQL 结果，`totalMatched` 不再依赖另一份 `COUNT(*)` 快照。`filters` 支持两种 JSON 形式：object（列名到等值，如 `{"user_id":"u1"}`，兼容旧入口）与条件数组（如 `[{"column":"points","op":"gt","value":"5"}]`，运算符覆盖 `eq`、`ne`、`gt`、`gte`、`lt`、`lte`、`contains`、`notContains`、`startsWith`、`endsWith`、`in`、`notIn`、`isEmpty`、`isNotEmpty`，允许同列多条件，条件间为 AND）；两种形式的用户输入都不进入 SQL，只在 API Server 内存中过滤。请求页码超过实际总页数时钳制到末页，零结果固定返回第 1 页。存在第 50,001 条哨兵行时响应必须返回 `scanLimitReached=true`，后台固定分页栏上方明确提示匹配总数和分页结果可能不完整，不得把扫描范围外的数据误报为不存在。候选 SQL 响应体仍受 32 MiB 和 20 秒硬限制；宽表即使每页条数很小也可能整次拒绝，不会返回部分结果。实时写入仍可能改变相邻请求的候选快照，精确审计应使用对应业务表的专用查询而不是通用浏览页。
 
-后台表查询页的结构化筛选条件支持逐条勾选启用或停用；停用条件不会进入请求，但会保留当前字段和值。`in` / `notIn` 使用逐项值标签编辑，支持粘贴多行值，避免把字符串中的逗号误拆成多个条件。
+后台表查询页的结构化筛选条件支持逐条勾选启用或停用；停用条件不会进入请求，但会保留当前字段和值。表单和标题区的查询入口共用同一完整性校验，未完成的启用条件不会静默丢弃。`eq` / `ne` 和比较、文本运算符一样必须提供标量 `value`；显式空值判断使用 `isEmpty` / `isNotEmpty`。`in` / `notIn` 使用逐项值标签编辑，支持粘贴多行值，避免把字符串中的逗号误拆成多个条件。行内交互控件的键盘事件不会冒泡触发行详情，空字段详情复制会给出失败反馈。
 
 ## Issue 与交接