Step 3 实际产出价值低且有副作用：
1. 「行政区划孤儿编码检查」只判断字典表 c_bri_xzqh 是否存在，
   没有真正跑 LEFT JOIN 找孤儿（代码注释里写了「可扩展」）
2. 「数据质量问题检查」只是占位，返回空列表
3. 「验证合并候选实际行数」有点用，但 result 已经直接覆盖 Step 2 的输出

最致命的是 _run_step3 返回 section_key='redundancy_fields' —— 这会
反向覆盖 Step 2 的 LLM 分类结果（classification / reasoning /
recommendation 全没了，只剩 Step 3 的简单 field + table_count 列表）。
也就是说 Step 2 的 LLM 工作被 Step 3 默默销毁了。移除 Step 3 同时也修了
这个覆盖 bug，Step 2 的分类结果能正确进入报告。

改动：

- 删除 web/core/step_impl/step3_verify.py
- 删除 web/sql/verify/ + web/sql/xzqh/ 整个目录（仅 Step 3 使用）
- orchestrator.py：
  - STEP_REGISTRY 移除 (3, 数据验证, _run_step3, ...)
  - STEP_DEPENDENCIES 移除 3: {1, 2}
  - step_name() 移除 3: '3_verify'
  - 删除 _run_step3 函数
  - 顶部 docstring 重写：6 步流程 + 移除 Step 3 的原因
- routes.py：list_steps() 不再返回 Step 3
- job_manager.py：all_steps 默认值改成从 STEP_REGISTRY 取
  （保持单一来源，避免硬编码漏改）
- frontend index.html：
  - form.steps 默认 [1,2,3,4,5,6,7] → [1,2,4,5,6,7]
  - 兜底过滤也加上 n !== 3（兼容旧本地缓存残留）

注：未触及 workflow/ 旧 CLI 目录，它走的是另一套独立实现。

行为：
- UI 上「执行步骤」区只有 6 个分析 Step
- /api/steps 返回 6 项
- 主流程跑完后无条件生成报告（Step 8 拆出来之前的约定不变）
- Step 2 LLM 分类结果不再被覆盖，能正确进冗余字段报告