[Feature Request] Add per-message timestamps and session clock for reliable time tracking

#Feature Request: Give Claude reliable access to the passage of time

##OBSERVATION
Humans track time two ways: by estimating it (a felt sense of duration) or by checking a clock. Claude can do neither reliably. It has no felt sense of elapsed time — so any duration it offers from "judgment" is confabulation, not estimation. And while it can read a clock when a tool is available, it has no persistent clock across a conversation: it cannot perceive the gap between when I send one message and the next. If I step away for three hours, Claude sees two adjacent messages and no elapsed time.

##WHY
This produces a specific, recurring failure: Claude misjudges how long a user has spent on something, because it conflates conversational length (number of messages) with elapsed time (wall-clock duration). A task that took many messages over a few minutes gets overestimated; a task where the user disappeared for hours between two messages gets underestimated. The errors are systematic, not random — and worse, they're delivered with the confidence of an observation, because a stated duration looks like a measured fact even when it was fabricated.

The current honest workarounds are limited: Claude can read a clock when responding (giving "current time"), but cannot track gaps between turns, cannot measure session duration, and cannot tell how long a user worked between messages — the exact things users naturally expect it to know.

##The request
Give Claude reliable access to the passage of time — not the ability to guess at it (that's the wrong fix; guessing is the bug), but a real signal it can read. Concretely, this could be:

• Per-message timestamps Claude can see — so it can compute the actual gap between turns rather than infer it from conversational context.

• A persistent session clock — start time and current time available, so session duration is measurable rather than estimated.

• An explicit "unavailable" state — when no timing signal exists, Claude should be able to say "I can't measure that" cleanly, rather than feeling pressure to produce a number.

##THE PRINCIPLE
The goal isn't to make Claude better at estimating time — it has no faculty to improve there, and estimation is precisely what produces confident-wrong answers. The goal is to root time in a readable source, the way a human checks a clock instead of trusting their gut. A measured timestamp can't confabulate; a felt sense always can. Giving Claude a clock it can actually read — including reading "no signal available" — turns time from a thing Claude fabricates into a thing Claude reports. That's a real step in usability: users could trust Claude's sense of "how long" because it would finally have one grounded in measurement rather than vibe.