File-tree requests from before a reset can overwrite newer state

Description

File-tree requests that finish after the store is reset can interfere with newer requests. reset() clears the in-flight map, but an old request's finally unconditionally deletes the new request for the same relative directory. A subsequent list starts a duplicate request instead of joining the pending one.

When the workspace changes away and back, the old response also passes the directory check. It can overwrite the new file list or report a stale error and clear the new request's loading state.

OpenCode version

Reproduced against dev at 57ef382843 using createFileTreeStore.

Steps to reproduce

1. Start a root directory listing and leave its response pending.
2. Reset the file-tree store, as workspace switching does, and start a new root listing.
3. Complete the old request while the new one is pending. Another list call now starts a third request instead of sharing the second.
4. With the same workspace selected after reset, complete the new response before the old response. The old file list replaces the new one.

Deterministic tests exercise the real store with deferred list responses. These are store-level reproductions; a desktop UI recording has not been captured.

Expected: only the request currently registered for a directory may update that directory or remove its in-flight entry.

Operating System

Platform-independent; tested on macOS.