fix: preserve timely-transient metadata during full replay

[huangzesen]

Summary

Preserve every recorded holder of LingTai's timely-transient metadata families during full-history model replay:

• agent_meta + guidance
• notifications + notification_guidance

Only the latest holder per family is current/authoritative. Older holders remain model-visible historical traces and must not be treated as new instructions; producer channels remain the source of truth for actionable content.

This keeps full replay from rewriting earlier serialized prefixes merely to remove small stale metadata copies. Summarize remains the only rebuild mechanism that replaces a historical tool-result body.

What changed

• remove shared newest-holder detection and stale-key filtering from the Anthropic, OpenAI Chat Completions, Responses/Codex, and Gemini converters
• make stateless Claude Code full-history rendering consume each recorded ToolResultBlock.content directly
• retain the existing Codex frozen-output/epoch behavior for in-place canonical mutations and summarize replacement
• keep synthetic notification-holder skeletonization as a separate pre-replay canonical mutation; normal historical tool results keep their metadata
• strengthen resident prompt/readme guidance that only the latest holder per family is current and older copies are historical/non-actionable
• update code comments, configuration comments, manuals, and anatomy to the same contract
• replace old filter-oriented tests with cross-provider preservation regressions, summarize-marker coverage, empty-envelope coverage, and Codex within-epoch freeze coverage

No compatibility flag or shim is added; the old intermediate helper surface is removed.

LICC Notification Contract assessment

src/lingtai/services/LICC_NOTIFICATION_CONTRACT.md v2 was reviewed because this change touches notification ownership paths.

No contract version or text change is needed. This PR does not change:

• event identity
• attention-vs-context placement
• producer read state or dismissal semantics
• producer authority/source-of-truth rules
• synthetic-holder ownership or live-holder movement

It changes only the model-facing replay projection of already-recorded holders. The existing contract already says that a lingering context block is not proof of an unhandled event, which is consistent with the strengthened latest-only guidance.

Validation

Candidate commit: 5d5307053bcb83fe5d650149674aaa4af3a5adf9

• git diff --check clean
• exact reviewed patch: 19 files, 303 insertions, 374 deletions
• reviewed patch SHA-256: 14dfb5aa320c4c918377f09a037aac53d6cbbac8802b79197d1ac11d4ab3b614
• AST parse passed for all changed Python files, including both owning base_agent comment repairs
• direct no-write assertions passed for four wire converters × five cases
• direct Claude Code, Codex rebuild/freeze, summarize-marker, and meta-readme assertions passed
• read-only architecture and LICC maintenance assertions passed
• independent exact-model final review: READY, with 0 blocker / 0 high / 0 medium findings

I intentionally did not run local pytest: this work was performed under a no-delete/no-cleanup boundary, and pytest's basetemp retention can delete earlier retained evidence directories. The changed tests are included for the repository CI matrix.

Open-PR overlap and merge order

Mechanical changed-file intersection and git merge-tree --write-tree checks found clean combined trees with currently open PRs #917, #908, #887, and #877.

PR #914 (fix(notifications): prevent stale email snapshots in replay) overlaps this replay surface and is already DIRTY / CONFLICTING against current main before this branch is considered. Its atomic email snapshot projection remains conceptually valid, but its current implementation is based on the old filtering-helper architecture.

Safe queue order:

1. review this PR independently against current main;
2. do not merge fix(notifications): prevent stale email snapshots in replay #914 unchanged afterward;
3. rebase/rescope fix(notifications): prevent stale email snapshots in replay #914 onto the resulting direct-converter architecture, retain only the atomic email snapshot projection, then rerun combined-state tests and review.

This PR does not claim that the current #914 head is merge-safe.

Scope

No runtime installation or refresh, configuration/auth change, deletion/cleanup, release/tag, issue closure, or merge is performed here. This PR contains no closing references.