#10725: fix: re-read session store inside lock in updateSessionStoreEntry

## Summary - `updateSessionStoreEntry` reads the session store inside a lock but uses the cached version (`loadSessionStore(storePath)` without `skipCache`) - This means concurrent writes between the cache read and the lock acquisition can be silently overwritten - The sibling function `updateSessionStore` (line 270) already handles this correctly with `{ skipCache: true }` and an explicit comment: _"Always re-read inside the lock to avoid clobbering concurrent writers"_ - This fix applies the same pattern for consistency and correctness ## 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> - Fixes a race in `updateSessionStoreEntry` by re-reading the on-disk session store *inside* the session-store lock using `loadSessionStore(..., { skipCache: true })`. - Aligns behavior with `updateSessionStore`, which already forces a fresh read under the lock to avoid overwriting concurrent writers. - Adds an explanatory comment documenting why cache bypass is required in the locked section. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk. - The change is a small, localized correctness fix that matches an existing locking pattern in the same module and does not alter public APIs; it reduces the chance of lost updates under concurrency. - src/config/sessions/store.ts <!-- greptile_other_comments_section --> <!-- /greptile_comment -->