- BasedataAreaEquTreeVo 新增 useMode，构树时透传 basedata_eqpbook_channel.use_mode
- getAreaEqubookTreeSelectForFilter 只返回有子节点的数据：
  先按设备查询通道，无通道的设备不再作为叶子节点返回，
  其所在区域分支也随之过滤
- 通道列表按设备缓存复用，避免构树时重复查询

问题：
- 每次点击摄像头都生成随机 streamId 并调用 ZLM addStreamProxy，
  拉流代理在无人观看后也不会回收；
- 长时间使用后 ZLM 累积大量 0 观众代理（现场最多 201 路），
  占满 NVR 并发连接，新建流拉不到数据；
- /api/v1/stream/stop 为空实现，停止播放时不会释放拉流；
- 表现为预置位配置中点开设备树后视频黑屏，WebRTC 信令等待 15s 超时。
改动：
- streamId 改为按摄像头确定性生成（htjc_ + cameraCode），
  同一摄像头复用同一路拉流代理，避免重复拉流；
- 建立代理前先用 getProxyInfo 判断，已存在则复用；
- 实现 stop：delStreamProxy 删除代理后再 close_streams(force=1)
  关闭媒体源，兼容 ZLM auto_close=0 的场景；
- 增加 Redis 观看者计数，最后一个观看者退出时才真正关流；
- 新增空闲流兜底回收：清理 htjc_ 前缀、无观众且空闲超过 120s 的代理，
  在取流时异步触发并做 30s 节流；
- 补充 ZLM API 常量及代理 key（vhost/app/stream）构造。

支持 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=任务单独报告';

上一提交（移除 KEYS 全库扫描）把"清理窗口外策略 key"的动作从"每个执行时刻一次"提到
"每个任务一次"。但按分钟执行的间隔任务，其 exeTimes 由 getExecTimesByMinute 生成到
次日 00:00，会超出任务配置的 intervalEndTime：原先每次存 key 前的清理会把窗口外的 key
删掉（除最后一次外），提取到循环外之后这些窗口外的 key 会全部留存，导致调度器在配置
窗口之外仍然执行任务。

本提交在按分钟执行的循环内补上守卫：晚于 intervalEndTime 的时刻直接跳过，既不清理也不
生成策略 key，与"只保留 finalDate 之内的策略 key"的原意保持一致（按小时执行的 exeTimes
本来就以 intervalEndTime 为界，不受影响）。

现象：巡检服务（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，对删除/遍历场景无影响），未改动任何业务判定逻辑。