#10726: fix: re-read session store inside lock in updateLastRoute

## Summary - `updateLastRoute` acquires the session store lock but reads the store without `skipCache`, which can return a stale cached copy and silently overwrite concurrent writes - The sibling function `updateSessionStore` (line 272) already does this correctly: `loadSessionStore(storePath, { skipCache: true })` with the comment _"Always re-read inside the lock to avoid clobbering concurrent writers"_ - This fix applies the same established pattern to `updateLastRoute` - Related to PR #10725 which fixes the same issue in `updateSessionStoreEntry` ## Test plan - [x] All session store tests pass (7 tests) - [x] Change matches the established pattern in `updateSessionStore` Generated with [Claude Code](https://claude.com/claude-code) <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> - Updates `updateLastRoute` to re-read the session store *inside* the file lock using `loadSessionStore(storePath, { skipCache: true })`. - Aligns `updateLastRoute` with the existing concurrency-safe pattern already used in `updateSessionStore` to avoid clobbering concurrent writers due to cached reads. - No other functional changes outside the session-store load behavior in `src/config/sessions/store.ts`. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk. - Change is narrowly scoped and matches an established pattern in the same module to prevent stale cached reads under the session-store lock; no behavioral changes beyond improving concurrency correctness. - No files require special attention <!-- greptile_other_comments_section --> <!-- /greptile_comment -->