Windows: Solution Explorer / workspaceSymbols serve stale data after rename (3 e2e failures)

Three solution-explorer.test.ts assertions fail on Windows and pass on Linux:

After unsaved rename 'DiskVersion' -> 'BufferVersion', tree must show 'BufferVersion'
  — BUG: sharplsp/workspaceSymbols reads from disk instead of VFS, so it shows stale disk content
After rapid renames Step0 -> Step1 -> Step2 -> Step3, tree must show 'Step3'
  — BUG: tree is always one step behind, showing stale data from disk
After renaming 'Alpha' to 'Bravo', tree must show 'Bravo'
  — stale data bug: tree still displays the previous class name

Not a regression

solution-explorer.test.ts has not changed since #37. What changed is that the VS Code
suite now runs its full feature surface on Windows runners for the first time
([DIST-CI-WIN-VSIX] / [DIST-CI-LAYOUT], PR #189). This defect is therefore present in the
currently shipped release; it is newly visible, not newly introduced.

What is already ruled out

The obvious suspect — workspaceSymbols reading disk instead of the VFS — does not match
the code. parse_file_symbols calls vfs.read_live_or_disk, and
Vfs::get_content_for_path_canonical already handles the Windows-specific path spellings:
\?\ verbatim prefixes, case-insensitive drive letters, 8.3 short names, .. components
(see the native_paths_equal comment and the
get_content_for_path_canonical_resolves_indirect_spellings test). So the assertion
messages, which predate that work, are probably misattributing the cause.

"Tree is always one step behind" is the more informative symptom: it suggests a
cache/debounce/ordering problem in the refresh path rather than a bad read, and one whose
timing only loses the race on Windows.

Suggested starting points

1. Instrument sharplsp/workspaceSymbols: log whether each file resolved from the VFS or
   fell through to disk (read_live_or_disk already has a trace! on the miss path). If
   there are no misses, the stale data is downstream of the read.
2. Check the explorer's refresh debounce and whether a refresh triggered by rename N can be
   answered with a response computed for rename N-1 — a missing generation/version guard
   would produce exactly "always one step behind".
3. Confirm the file list the sidecar reports uses the same path spelling the VFS is keyed
   by; a mismatch there bypasses the VFS without ever hitting read_live_or_disk.

Reproduce with the Windows explorer chunk:
make _test-vsix-win CHUNK=explorer

Refs [DIST-CI-WIN-VSIX].

Start with solution-explorer.test.ts and reproduce the failures using make _test-vsix-win CHUNK=explorer. Trace sharplsp/workspaceSymbols through parse_file_symbols and read_live_or_disk, then inspect the explorer refresh debounce, response ordering, and reported file paths. Done means the Windows explorer chunk passes for unsaved and rapid renames without stale names.