fix: preserve session createdAt/lastActivityAt across a daemon restart

[saucam]

Session ordering was not surviving restarts. Root cause is two unconditional lines in the Session constructor:

this.createdAt = new Date().toISOString();
this.#lastActivityAt = this.createdAt;

They run on resume too, so every restart re-dates every session to the restart moment.

Two consequences

• Age resets. A session created weeks ago reports as brand new.
• Ordering collapses. The session list's recency key is lastActivityAt ?? createdAt, so after a restart every session ties on the same instant — and the attention ordering from feat: order the session list by attention, not by when you created it #300 falls back to insertion order, which is precisely what it was built to replace.

The data was already there

TranscriptMeta persists both fields, and they were already being read: SessionManager.resumeSortKey sorts the resume pass by meta.lastActivityAt.

So the manager iterated resume in the correct order, and each Session constructor then overwrote the timestamps a moment later. The right values were on disk, read, and discarded.

The fix

1. SessionCreateOptions gains optional createdAt / lastActivityAt
2. Constructor prefers them: opts.createdAt ?? new Date().toISOString()
3. The resume call site passes meta.createdAt / meta.lastActivityAt

New sessions are unaffected — no opts means stamped fresh, with activity falling back to creation.

One deliberate edge case: meta written before lastActivityAt existed degrades to createdAt, not to now. Falling back to now would sort the most ancient session as the most recently active one — the inverse of the intent, and worse than the bug being fixed.

Verification

lint + typecheck clean, 2386 pass / 0 fail. Four new tests: both timestamps preserved on resume, both stamped fresh for a new session, the partial-meta fallback, and a simulated restart confirming two sessions stay distinguishable by recency (the actual regression).

🤖 Generated with Claude Code