Local history: first save after reload duplicates an entry instead of merging within the merge window

### Bug description

`WorkingCopyHistoryModel.addEntry` (`src/vs/workbench/services/workingCopy/common/workingCopyHistoryService.ts`) reads `this.entries.at(-1)` to decide whether the newest entry should be replaced (merge window) without awaiting model resolution first. Every other entry-mutating path (`removeEntry`, `updateEntry`, `getEntries`, `store`) awaits `resolveEntriesOnce()` before touching `this.entries`; a freshly constructed model starts with `entries = []` and resolves lazily.

Consequence: on the first save of a file after session start (or after a window reload), `lastEntry` is undefined even when the on-disk `entries.json` holds a same-source entry seconds old, so `doAddEntry` always runs and a duplicate history entry is created instead of replacing the previous one. The `workbench.localHistory.mergeWindow` setting (default 10s) documents that "the last entry in local history is replaced" for saves within the interval, which this path violates.

Concrete sequence: save `file.txt`, quit within the merge window or let the scheduler flush, reopen the window, save again 5 seconds later - two entries 5 seconds apart with identical source appear where one replaced entry was promised.

### Steps to reproduce

1. Enable local history for a workspace, save a file.
2. Reload the VS Code window.
3. Save the same file again within `workbench.localHistory.mergeWindow`.
4. Open Timeline (Local History): two entries exist instead of one replaced entry.

### Expected behavior

`addEntry` resolves pending entries from disk first (like its sibling methods), then applies the merge-window replacement logic against the real latest entry.