MemoryConsolidator 在 MEMORY.md 缺失或为空时，已有水位导致旧账本不参与重建

## 环境

- `agentscope-harness` 2.0.3：经由集成该版本的应用端到端复现（MEMORY.md 缺失时，合并结果只包含水位之后账本的内容）
- 当前 `main`：父提交 `c6af7818` 经代码走读确认缺陷仍在；修复提交 `246c3b3f` 基于该提交
- 影响所有文件系统后端（Local / Sandbox / Remote）——`MemoryConsolidator` 与后端无关

## 问题描述

Harness 的记忆模型分两层：只追加的每日账本（`memory/YYYY-MM-DD.md`）和由 `MemoryConsolidator` 定期重写的策划层 `MEMORY.md`。每次合并的输入组装方式是：

> 当前 MEMORY.md（为空时用占位符 `(empty)`）+ 水位（`memory/.consolidation_state`）之后修改的每日账本 → 覆写 MEMORY.md → 推进水位

该机制依赖一个从未被校验的前提：**MEMORY.md 承载着此前合并保留下来的长期记忆**。当 MEMORY.md 确实缺失或为空、而隐藏的水位文件还在时（例如手动清理或误删了 MEMORY.md 但没有删除水位），下一次合并就会把"水位之后的账本"合并进 `(empty)` 并整体覆写文件。此后：

- 水位之前**未再次修改**的旧账本不会自动重新纳入；
- 整个过程缺少针对该状态的告警，合并正常完成、水位照常推进，无法事后察觉。

每日账本（事实源头）仍然保有这些内容，数据原则上可恢复——但策划视图不会自行回到正确状态。

## 复现步骤

确定性复现——缺陷出在输入组装阶段，与模型的返回无关：

1. 准备一个工作区：
- `memory/2025-06-14.md`（mtime 早于水位），内容 "older day facts"
- `memory/2025-06-16.md`（mtime 晚于水位），内容 "fresh day facts"
- `memory/.consolidation_state` = `2025-06-15T12:00:00Z`
- 不存在 `MEMORY.md`
2. 调用 `MemoryConsolidator.consolidate(rc)`。
3. 检查发给模型的 user 消息：只有 `### 2025-06-16.md` 和 `(empty)`——`2025-06-14.md` 被水位过滤掉了。模型输出随后覆写 `MEMORY.md`，水位照常推进。

**期望行为：** 策划视图缺失或为空而水位已存在时，应识别为"视图丢失"，从**全部**每日账本重建（与首次运行相同的输入组装）——或者至少拒绝合并并记录警告，而不是静默覆写。

## 相关问题（本补丁不解决）

- `WorkspaceManager.readMemoryMd()` 在瞬时读取失败（I/O 错误等）时同样返回 `""`，与"文件确实为空"无法区分；此时即使 MEMORY.md 本身完好，也会进入同一条重建路径。
- 部分账本读取失败目前不会阻止合并继续执行。

## 建议修复

在 `MemoryConsolidator.consolidate()` 中，读取当前 MEMORY.md 之后：

```java
if (currentMemory.isBlank() && !watermark.equals(Instant.EPOCH)) {
log.warn("MEMORY.md is blank while a consolidation watermark exists ({}) — "
+ "rebuilding from all daily ledgers", watermark);
watermark = Instant.EPOCH;
}
```

把本次运行的局部 `watermark` 归零后，全部账本自动进入合并输入，且误导性的 `(since ...)` 提示词标签也会随之消失——两者共用同一个变量。MEMORY.md 是账本的派生视图，从事实源头重建才能让语义自洽；"无新账本则跳过"的短路逻辑在视图存在时依然适用。稍后提交 PR。