[Bug][Windows] Plugin migration freeze keeps profiles/web/node_modules junction on stale generation - sidebar 'Open with' silently loads unpatched client code #391

Describe the bug

On Windows, after plugin updates, the sidebar file tree context menu 'Open with -> File Manager (资源管理器)' silently does nothing — Explorer never comes to the front (it opens behind the DSH window or not at all), while 'Open with -> VS Code' works fine.

The root cause is deeper than the plugin code: the plugin generation migration freeze leaves profiles\web\node_modules\<plugin> junctions pointing at stale generations, so the dsh web /plugins/ route keeps serving old (unpatched) client code — even though the 'active' generation on disk is correct.

Environment

• DSH Desktop 0.8.x (Windows 10/11)
• dsh-better-sidebar 0.18.0
• harness profile: web

Root cause (evidence)

1. Migration frozen — profiles\web\.generations-deferred.json:

   {
     "protocol": 6,
     "fingerprint": "c4d5c7fad5faf3ae895d42fa6dbda28af5ea002505fb25781fb1ea654df11ac9",
     "reason": "dsh-builtin-browser failed peer validation: electron resolves outside the generation and installation closure: electron",
     "failedAt": "2026-09-11T07:13:02.965Z",
     "retryAfter": "2026-09-11T13:13:02.965Z"
   }

   harness.log: profile maintenance frozen: migration deferred (previously failed preflight for this exact fingerprint)

2. Stale junction — profiles\web\node_modules\dsh-better-sidebar is a junction that still points to an old generation (...\dsh-better-sidebar+0.18.0+7d0ce9355c39\..., ~5 days old) instead of the active one (...\dsh-better-sidebar+0.18.0+40ef654e32d0\...), even after a full DSH Desktop restart and after retryAfter passed.

3. dsh web serves plugin client bundles from that junction (/plugins/??dsh-better-sidebar/client.js&rev=..., response cache-control: public, max-age=31536000, immutable). The renderer therefore keeps loading the stale client code: the 'reveal' branch never calls the desktop bridge, falls back to spawning explorer.exe from the harness (which cannot foreground a window because the harness runs windowsHide + detached), so Explorer opens behind DSH — the user sees 'nothing happened'. VS Code keeps working because the URL branch goes through a different route (cmd /c start), and the old rundll32 happened to work for vscode://.

4. Manual workaround that fixed it: re-point the junction at the patched generation (cmd /c rmdir <link> + New-Item -ItemType Junction) then fully restart DSH Desktop. rev is regenerated per harness start, which also bypasses the immutable HTTP cache.

Expected behavior

• When generation migration fails, the harness must not silently keep loading stale generation code:
  • profiles\web\node_modules\<plugin> junctions should stay on the newest installed generation, or migration should keep retrying once the peer-validation blocker is resolved.
  • A user-visible warning in the Desktop UI would have saved hours of debugging — currently there is zero on-screen indication that plugins are running from old code.
• dsh-builtin-browser's peer validation (electron resolves outside the generation and installation closure: electron) looks like a false positive (that plugin deliberately bundles/spawns its own Electron) and should not freeze migration for the whole profile.

Suggested fix

• Re-evaluate dsh-builtin-browser peer validation (electron is intentionally resolved outside its generation).
• On deferred migration, either update junctions to the active generation anyway, or surface an explicit error/warning in the UI instead of silently serving stale plugin client bundles.