[MODEL] Relative-time phrases ("yesterday", "just now") derived from conversation distance instead of timestamps (successor to #79731)

Successor to #79731 (Same-session events described as "yesterday"). Lifecycle automation closed it on 2026-09-09 with "Please open a new issue if this is still relevant". No open issue owns this class. The adjacent open reports cover different failures, listed under Out of scope below.

Behaviour

The model attaches relative-time phrases such as "yesterday", "earlier today" or "just now" to past events based on how far back in the conversation they are, not on their timestamps. It fails in both directions:

• Inventing elapsed time: in #79731, events from the same session were called "yesterday".
• Collapsing elapsed time: in #87214, an event six weeks old was called "just now". That report was closed as a duplicate of #73800, which was later closed for inactivity.

Evidence

• #79731, original report (2026-07-21): same-session events called "yesterday", Fable 5.
• Opus 5, Claude Code 2.1.222, Claude Desktop on Windows, 2026-08-09 (my comment on #79731):
• The session started at 10:34Z, and the transcript places the discussion in question between 10:45Z and 11:05Z.
• At 11:25Z, Claude called it "the archive.org rationale yesterday".
• The current date was in context, and a memory entry Claude had written earlier in the same session used the absolute date. When challenged, Claude checked the chronology and retracted.

Both cases predate Opus 5.5. I'll add a recurrence on the current model here if one occurs.

Requested

A model-side rule: Don't give a relative time for an event unless there is a timestamp for it. Without one, use a neutral phrase such as "earlier in this session". "Earlier in this session" would have been accurate in the case above without needing a precise time.

Out of scope, with owners

• Dating a past event to the current date after a midnight rollover: #91224
• Invented clock readings: #92732
• Per-message timestamps as a product-side aid: #91260