支持 enabled 开关控制是否推送中恒,inspect.taskStatus-delete-push.enabled:false

用于清理任务列表脏数据：按 task_patrolled_id 删除 patrol_task_status 记录后，
调用 jb-nessp-external/api/mqtt/sendTopic 推送 topic/env/delete 消息通知中恒。

- inspection_report 新增 report_scope：merge=合并报告，single=任务单独报告
- 归档时写入报告粒度；单任务归档仍置 file_status=1，合并报告头存逗号拼接的多个任务执行标识
- 进度条查看报告优先取该任务自己的报告（report_scope=single），没有才回退合并报告
- 报告列表支持按报告粒度筛选；对外只推送合并报告，任务单独报告仅站内查看/下载
- 任务列表/进度条返回报告下载地址：新增 inspect.file.url-prefix，与场站编码、file_path 拼接
- 报告名去除空白字符，避免拼进下载地址后不可用
- 定时归档查询不再按 file_status 过滤（合并归档不再逐任务置归档状态）
- 新增 sql，需在目标库手工执行一次，ALTER TABLE inspection_report
                         ADD COLUMN report_scope VARCHAR(16) NULL COMMENT '报告粒度：merge=合并报告，single=任务单独报告';

现象：巡检服务（dliip-patrol）容器连续约 9 小时 unhealthy；Tomcat 200 个请求线程
全部阻塞在 Lettuce（AsyncCommand.await 无超时，永不失败），容器 CPU 在 2%~500% 间跳变，
健康检查（curl 127.0.0.1:9901，10s 超时）连续 284 次超时。

根因：inspect-job 定时调用 /exec/makeCurrentDayTask，该接口遍历所有启用任务，对每个
"间隔执行"任务的每个执行时刻调用一次 parseTaskToRedis，而 parseTaskToRedis 内部用
redisService.keys(TASK_CODE@taskCode@*) 做全库扫描来清理策略 key。于是一次调用会对
Redis 发起成百上千次 KEYS：Redis 单线程，单次 KEYS 约 13ms 且返回体巨大（实测输出
8MB/s，单个客户端连接积压 321 条回复 / 5.8MB 输出缓冲），KEYS 执行期间其它所有客户端
的命令全部排队，实测 Redis 响应延迟 avg 287ms / max 1365ms，进而导致上游业务请求堆积、
Tomcat 线程池被占满、健康检查排不上队而超时。

修复：
1. RedisService 新增 scan(pattern[, count])，基于 SCAN 游标分批读取，不阻塞其它客户端；
   原 keys() 标记 @Deprecated 并注明生产环境禁用。
2. 全仓库 11 处 redisService.keys() 调用点改为 scan()。
3. PatrolTaskExecController：抽出 cleanTaskKeysAfter()，策略 key 清理由"每个执行时刻一次"
   改为"每个任务一次"，一次 makeCurrentDayTask 的 KEYS 次数从成百上千次降到与任务数同量级。
4. PatrolTaskController：批量删除任务时原为 N 个 taskId 扫描 N 次全库，改为只扫描一次。

影响面：仅改变"按 pattern 查找 key"的实现方式（KEYS→SCAN，语义等价；SCAN 可能重复返回
同一个 key，对删除/遍历场景无影响），未改动任何业务判定逻辑。

fix: 1.机器狗红外读数只保留一位小数;2.优化巡视方案列表接口加载速度;3.调整联合任务状态的展示优先级