[BUG] Redis 聊天记忆读取损坏记录时不应静默返回删减后的正常历史 #52

基线与代码依据

Extensions 495414b76a37aca4d7c1022d973a8e5b9a7e92e6；Core 76d44429fdaa6a69320e21a1cb77119d0889d792。两个仓库已更新，远端均无新提交。

三个 findByConversationId 均在 deserializeMessage 后 filter(Objects::nonNull)。

已复现问题

Base.deserializeMessage 遇 JacksonException 记录日志并返回 null，三个客户端过滤 null 后正常返回列表。调用者无法区分完整历史和已丢弃损坏记录的部分历史。

实际 Redisson 仓库读取 [合法消息 JSON, "{invalid-json"]，返回正常结果且只有一条消息，没有向调用者表达损坏/部分成功。日志存在不等于调用契约已经通知调用方。

缺失的可能是 system、assistant tool call 或 tool response，后续执行可能在不完整上下文上继续，并把删减快照写回存储。

交付与验收

• 明确默认损坏处理策略：显式异常，或可辨识的部分读取/隔离结果；不能把部分历史伪装成完整成功。
• 若保留容错读取，必须显式配置并提供损坏位置、数量和诊断信号；日志不默认包含正文。
• 部分读取不得无提示触发覆盖/修复写回；定义兼容格式、未知类型和真正损坏的区分。
• 三客户端覆盖中间记录损坏、全部损坏、工具消息配对、旧格式、空历史，验证一致行为。
• 对历史宽松读取行为的收紧给出升级说明；不通过强制缺失消息为 USER 或空串修补历史。

验证边界与变更约束

本次使用当前实际编译类进行可执行验证，Redis 客户端/命令边界使用 Mockito 替换，未声称已通过真实 Redis、TLS 握手或集群验收。修复需增加真实后端验证。优先局部修复；若涉及公开 API、默认行为、坐标或存量数据，说明消费者影响、兼容替代、迁移/回滚及目标版本，不等待 Agent/Workflow/Loop 全局重构。关联 #30、#34；#34 是包职责整理，本单是具体运行行为缺陷。