Feature Description
框架注入 user 消息的内部元信息块（<system_reminder>User ID: ..., Current datetime: ...</system_reminder>，由 provider_settings.identifier / datetime_system_prompt 控制）会随当轮 user message 被持久化进 conversations 表并永久滞留。
建议：astr_main_agent.py 的 _append_system_reminders()（master :973-1013）生成 TextPart(text=system_content) 时没有调用 .mark_as_temp() → ContentPart 默认 _no_save=False → dump_messages_with_checkpoints() 只过滤 _no_save 内容 → reminder 随当轮 user multipart message 写入 conversations。
与既有讨论的关系：
为什么现在值得再做一次：#9190 当时的方案是新增配置项，评审担心默认行为变化。但 master 后来引入了 _no_save / mark_as_temp() 机制——给 _append_system_reminders() 的 TextPart 补一个 .mark_as_temp() 是一行级改动：不需要新配置、不改变 prompt 内容、不影响 prompt cache（当轮请求内容完全不变），只改变"是否落库"。如果维护者认可这个方向，我愿意提交对应 PR。
期望：
- _append_system_reminders() 产出的内部块标记为 temp，不落库；
- 顺带评估：存量历史中已固化的大量 reminder 块，是否提供一次性清洗手段。
Use Case
版本 4.26.7 实测，已对照 master 代码确认行为依然存在。
本机实测规模：320 个会话中 307 个（95.9%）含泄漏，805/2680 条 user 消息（30%）携带该段，累计约 12 万字符。该文本随历史加载反复进入后续每一轮 prompt，并被会话摘要二次携带放大——长期运行的实例会持续浪费 token、污染上下文语义，且用户无法通过常规手段清除。
Checklist
Feature Description
框架注入 user 消息的内部元信息块（<system_reminder>User ID: ..., Current datetime: ...</system_reminder>，由 provider_settings.identifier / datetime_system_prompt 控制）会随当轮 user message 被持久化进 conversations 表并永久滞留。
建议：astr_main_agent.py 的 _append_system_reminders()（master :973-1013）生成 TextPart(text=system_content) 时没有调用 .mark_as_temp() → ContentPart 默认 _no_save=False → dump_messages_with_checkpoints() 只过滤 _no_save 内容 → reminder 随当轮 user multipart message 写入 conversations。
与既有讨论的关系：
为什么现在值得再做一次：#9190 当时的方案是新增配置项，评审担心默认行为变化。但 master 后来引入了 _no_save / mark_as_temp() 机制——给 _append_system_reminders() 的 TextPart 补一个 .mark_as_temp() 是一行级改动：不需要新配置、不改变 prompt 内容、不影响 prompt cache（当轮请求内容完全不变），只改变"是否落库"。如果维护者认可这个方向，我愿意提交对应 PR。
期望：
Use Case
版本 4.26.7 实测，已对照 master 代码确认行为依然存在。
本机实测规模：320 个会话中 307 个（95.9%）含泄漏，805/2680 条 user 消息（30%）携带该段，累计约 12 万字符。该文本随历史加载反复进入后续每一轮 prompt，并被会话摘要二次携带放大——长期运行的实例会持续浪费 token、污染上下文语义，且用户无法通过常规手段清除。
Checklist