It's not optimal to assigns time.Now() before acquiring the per-session lock. Two concurrent writers can therefore persist messages in an order that does not match their timestamps, which breaks chronology and any merge/sort logic that trusts created_at. Capture one now only after the lock is held, then use it for both msg.CreatedAt and meta.UpdatedAt.

Using omitempty on a time.Time field does not omit zero values with Go's encoding/json. Any uninitialized message written through SessionManager or rewriteJSONL will be serialized as 0001-01-01T00:00:00Z, which is garbage data masquerading as a real timestamp. Use *time.Time for an optional field, or guarantee population on every marshal path and add raw-JSON tests to prove zero timestamps are never written.

When using the JSONL backend, this timestamp is added only to the local copy passed into addMsg; callers such as turnState.recordPersistedMessage still keep the same message with CreatedAt == nil. After a mid-turn restore-point refresh (for example context-window retry compression), refreshRestorePointFromSession reads the persisted messages back with non-nil CreatedAt and compares them to the recorded messages with reflect.DeepEqual, so the current turn tail no longer matches and gets included in the rollback snapshot; aborting that turn can then leave partially persisted current-turn messages in history.

@alexhoshina The CreatedAt normalization (setting to nil on both sides before DeepEqual) in refreshRestorePointFromSession fixes the specific regression this PR introduced. However, after deeper analysis, there is a pre-existing issue with the same tail-matching logic: fields tagged with json:"-" — such as ToolCall.Name, ToolCall.Arguments, and Message.PromptLayer — are also lost during the JSONL roundtrip, so reflect.DeepEqual would still mismatch when comparing an in-memory persisted message (which has these fields populated) with a deserialized history message (which does not).

This means the tail-matching heuristic is fundamentally fragile — it breaks on any field that differs between the in-memory and serialized representations, not just CreatedAt.

I think the proper long-term fix is to introduce a unique MessageID so we can use set-subtraction instead of content-based DeepEqual matching. For now, the CreatedAt nil normalization is sufficient to fix this PR's regression. The json:"-" issue is pre-existing and unrelated to this PR — I'll file a separate PR to address it.