feat(保留期清理): 补齐 7 处只增不删的数据；修结果对象孤儿

审核发现一批表/元数据只增不删，且对象存储存在活跃泄漏：

- module-cleanup 漏收 task_result_item / task_result_payload 的 payload 指针，
  每晚删完行就在 json-server 桶留下孤儿对象；指针收集触顶从"截断后照样删整组"
  改为任务组二分拆分，拆到单任务仍触顶则整组不删并记 error（截断会让指针随行消失）
- 结果文件对象此前从不回收（只删 DB 行、对象留在桶里），现改为事务提交后
  按 file_result / task_file_job 的 result_file_url 逐个回收
- 新增 7 个保留期清理：device_log_file 元数据、price_track_loop_run、撞款扫描行、
  密钥用量日统计、紫鸟记忆过期行、PUBLISH 任务、BRAND 任务。后两者刻意不复用
  module-cleanup（BRAND 不写 biz_file_task；PUBLISH 单任务可达数万行），
  改为调各自既有的业务删除入口，保证结果对象与子表一起回收
- 未读通知补保留期（180 天，已读仍 90 天）；ZiniaoMemoryStoreService.deleteExpired
  此前全库无调用方（实现了没接线），现已挂定时任务

全部沿用既有范式：@Scheduled + 分布式锁单实例 + 分批 + 单轮批次数上限 + 失败只记日志。

backend-java/src/main/java/com/nanri/aiimage/config/NotificationProperties.java

@@ -67,4 +67,12 @@ public class NotificationProperties {
 
     /** 已读通知保留天数（超期自动清理），默认 90 天。 */
     private int readRetentionDays = 90;
+
+    /**
+     * 未读通知保留天数，默认 180 天（比已读长一倍）。
+     *
+     * <p>未读通知此前永不清理：不看铃铛的用户会无限累积。保留期给得更宽，
+     * 是因为未读意味着"用户可能还没看到"，但也不能永远留着。
+     */
+    private int unreadRetentionDays = 180;
 }