#6653: fix: persist archived session entry on /new or /reset

## Problem When users trigger `/new` or `/reset`, the previous session entry was being overwritten in `sessions.json` because the store is keyed by `sessionKey` (e.g., `agent:main:webchat`), not by `sessionId`. This caused old sessions to disappear from the sessions list in the UI, even though their transcript files (`.jsonl`) still existed on disk. Users could see 7 transcript files but only 1 entry in `sessions.json`. ## Solution Archive the previous session entry with a unique key (`${sessionKey}:session:${previousSessionId}`) before saving the new session. This preserves the old session metadata while still allowing the new session to be the "active" one at the original `sessionKey`. ## Changes - Modified `src/auto-reply/reply/session.ts` to persist `previousSessionEntry` to the store when `resetTriggered` is true ## Testing - ✅ All 14 tests in `src/auto-reply/reply/session.test.ts` pass - ✅ All 41 tests in `src/config/sessions` pass - ✅ Build completes successfully (`pnpm build`) ## AI-Assisted Disclosure This fix was identified and implemented with AI assistance (Claude). The bug was traced through analysis of the session initialization flow, where `previousSessionEntry` was captured but never persisted to the store during a reset. <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates `initSessionState` to persist (archive) the previous `SessionEntry` into `sessions.json` under a derived key when `/new` or `/reset` is triggered, preventing the previous session’s metadata from being overwritten at the primary `sessionKey` while a new active session starts. The change integrates into the existing session initialization flow by hooking into the same `updateSessionStore` write that updates `store[sessionKey]`, adding an extra write of `previousSessionEntry` under an archive key before storing the new entry. <h3>Confidence Score: 3/5</h3> - This PR is likely safe to merge, with a small risk of session-history loss in repeated reset scenarios due to archive key collisions. - The change is localized and follows existing store update patterns, but the archive key derivation can overwrite an existing archived entry if the same previous sessionId is archived again (e.g., repeated `/reset` without the active sessionId changing), which undermines the stated goal of preserving historical entries. - src/auto-reply/reply/session.ts <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13)) <!-- /greptile_comment -->