fix(memory): Event memory writes reusing existing page IDs

[yeshion23333]

问题是什么

模型在生成记忆时，会给每条记忆一个临时编号 page_id。后面的记忆关系和删除操作通过这个编号找到对应的记忆。

旧逻辑有三个问题：

• Event 可能误用已有 Profile 等记忆的编号，服务端会把它当成修改已有记忆，结果 memories/events 没有新增文件。
• 模型可能给不同的新记忆相同的编号。例如 Profile 和 Event 都使用 100，服务端就无法确定关系里的 100 到底指哪一条记忆。
• 当 Entity 错用了 Profile 的编号时，Entity 内容虽然会被拒绝，但使用这个编号的关系和删除迁移仍可能写到 Profile 上。

怎么修复

• Event 不再通过模型给的编号查找已有记忆，而是直接根据 Event 内容确定它在 memories/events 下的文件。
• 服务端会一起检查本次模型返回的所有新记忆。已有记忆使用 1–99，新记忆最终都使用不重复的 >=100 编号。模型给的编号可用就保留；已经被占用就改成下一个空闲编号。其他记忆先保留合法编号，Event 再使用剩余编号，尽量不改变原有行为。
• 例如模型同时返回 Profile=100、Event=100，服务端会调整为 Profile=100、Event=101，保证两条记忆最终编号不同。
• 如果一条关系仍然只写“100”，服务端无法知道模型想指 Profile 还是 Event。此时不猜测目标，直接丢弃这条关系；删除旧记忆时如果也无法确定关系应该迁移给谁，就跳过这次删除。这个场景不会再调用一次模型。
• 如果某个编号实际属于 Profile，模型却拿它修改 Entity，则拒绝 Entity 内容，同时丢弃使用该编号的关系，并跳过要把关系迁移给该编号的删除。
• Event 中消息范围不合法、无法确定写入目标等可修复问题，最多让模型修正一次。该修正只处理失败的 Event，不改动第一轮已经成功的其他记忆。

编号检查只处理当前这一次模型返回的内容。重新提取或重试时会重新计算，不会沿用上一次的编号占用状态。没有为编号冲突增加模型调用，也没有改变写入锁和 I/O 链路。

验证

• 覆盖 Event 误用已有编号、不同记忆使用相同编号、错误编号产生关系和删除迁移、Event 修正及重试隔离。
• Memory 测试：450/456 通过；其余 6 项为改动前已有的失败。
• React、Updater、Isolation、Trajectory 相关测试：91/91 通过。
• Ruff、compileall、git diff --check 通过。