fix(core): bump session time_updated on step lifecycle events

[Namit2003]

Issue for this PR

Closes #36893

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

On v2, time_updated gets set when a prompt is enqueued, but nothing touches it while the turn runs. So a session that's been busy for a while still sorts as old in the app and tui.

Added a small touch() in projector.ts that writes time_updated from the event's created time, and call it on step started/ended/failed. Execution succeeded/failed still keep time_updated as is, same as before. Didn't change the list sort order.

(Moved from dev to v2 per feedback on Discord.)

How did you verify your code works?

• new test in session-projector.test.ts: session starts at time_updated 0, uses TestClock to publish the step events at 5/9/12/15 and checks the row after each. fails on v2 without the fix, passes with it
• bun test + bun typecheck in packages/core, both clean

Screenshots / recordings

n/a

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate Found

PR #43847 - fix(core): bump session time_updated on execution events
#43847

Why it might be related:

• Both PRs address updating session.time_updated
• Both focus on core session lifecycle/execution events
• PR fix(core): bump session time_updated on execution events #43847 appears to handle execution events while the current PR (fix(core): bump session time_updated on step lifecycle events #49105) handles step lifecycle events (started/ended/failed)

These may be complementary fixes for different event types, or there could be overlapping scope depending on the implementation approach.

[holny]

Verified locally — the new test passes, and this matches what I found poking at the dev tree: neither insertMessage nor applyUsage advances SessionTable.time_updated (applyUsage explicitly preserves it), so step activity never moved a session in the list. Bumping through the projector is the right layer too, since time_updated then re-derives deterministically on a projection rebuild.

Two thoughts:

1. touch only fires on step boundaries, so a prompt that never reaches Step.Started (auth error, invalid model before the LLM call) still leaves the session sitting at its old position. Bumping on the user-message append would cover that, though the step-level fix already handles the reported case.

2. Nit: the update isn't monotonic (set time_updated = timestamp unconditionally). Events arrive ordered so it works out in practice, but something like max(time_updated, ?) would make it immune to any out-of-order timestamp.

Test covers the right sequence — good that it asserts the Failed branch too.

[Namit2003]

Thanks for checking it locally.

1. Fair point. I kept this to the step events since that's what the issue reports. Happy to add a bump on the user message too if a maintainer wants it in this PR, otherwise seems like a small follow-up.

2. Agreed it's not monotonic. Events are ordered so I left it simple, but max() is cheap. Can add it if there's a preference.

[holny]

Makes sense on both.

Events on a single stream are ordered, so I agree max() is cheap insurance rather than a fix — fine to leave it out if you'd rather keep the change small. The user-message bump is the maintainer's scope call either way; step-only does match what the report describes.