fix(windows): embed legacy cleanup tool in installer

[Sun-sunshine06]

Summary

• embed the legacy Windows cleanup helper directly into the NSIS installer so uninstall recovery no longer depends on sidecar files next to the downloaded .exe
• extract that embedded helper to %TEMP%\Open-Cowork-Legacy-Cleanup and offer to launch it immediately when the legacy uninstaller fails
• self-elevate the cleanup PowerShell script when machine-wide leftovers are detected, while still publishing the .cmd and .ps1 helpers with Windows build artifacts
• add regression coverage for the installer script, cleanup script, and workflow artifact patterns

Testing

• npx vitest run tests/build-windows-artifacts.test.ts tests/after-all-artifact-build.test.ts tests/windows-legacy-uninstall-remediation.test.ts tests/build-windows-script.test.ts
• npm run typecheck
• npx electron-builder --win nsis --publish never --config.directories.output=release-installer-embedded-cleanup-smoke

Verification

A direct Windows electron-builder smoke build completed successfully with the embedded-cleanup installer changes, and the shared artifact hook still emitted:

• Open Cowork-3.3.0-beta.7-win-x64.exe
• Open-Cowork-Legacy-Cleanup.cmd
• Open-Cowork-Legacy-Cleanup.ps1

[hqhq1025]

⚠️ Conditional Approve — NSIS flow verified correct, minor issues

I traced the full NSIS installer flow end-to-end. The self-elevation mechanism is safe (no injection vectors — $PSCommandPath + known switches only). ExecShell "open" on .cmd files works correctly.

Security notes

• Low risk: Predictable %TEMP%\Open-Cowork-Legacy-Cleanup path could be pre-empted with a directory junction by a local attacker. Consider clearing any pre-existing directory before extraction:

  IfFileExists "$OpenCoworkCleanupDir\*.*" 0 +2
    RMDir /r "$OpenCoworkCleanupDir"

• -ExecutionPolicy Bypass on the elevated process is standard for embedded utilities but could trigger AV heuristics. Worth noting in release notes.

Code quality (non-blocking, suggest follow-up)

• copyDirWithRetry has unreachable return maxAttempts after the loop (dead code)
• listRelativeFiles (after-pack.js) and collectRelativeFiles (stage-mcp-resources.js) are identical — should share
• Retry-with-backoff logic is duplicated between files
• Extracted temp files (%TEMP%\Open-Cowork-Legacy-Cleanup\) are never cleaned up after execution
• Most new tests are string-matching source code rather than behavioral tests — very brittle
• Windows cleanup helpers are copied twice when using build-windows.js (once via afterAllArtifactBuild hook, once in script exit handler)

[github-actions]

Findings

• [Minor] The new MCP after-pack regression test only greps scripts/after-pack.js as text, so it will keep passing if the hook stops loading or if the resources/mcp copy path fails at runtime. That leaves the exact packaging regression this PR is trying to prevent effectively untested. Evidence tests/after-pack-mcp.test.ts:7.
  Suggested fix:

  const afterPack = require('../scripts/after-pack.js');
  await afterPack({ ...fixtureContext });
  expect(fs.existsSync(path.join(appOutDir, 'resources', 'mcp', 'gui-operate-server.js'))).toBe(true);

Summary

• Review mode: initial. One minor testing-gap finding on the new after-pack coverage; I did not identify a higher-confidence runtime or security regression in the changed installer/build logic.

Testing

• Not run (automation; local Vitest startup failed in this checkout because vitest is not installed).

Open Cowork Bot

[github-actions]

[MINOR] This only asserts that specific strings still exist in scripts/after-pack.js, so it will still pass if the hook stops loading or if the staged MCP copy fails at runtime. That leaves the packaging path introduced in this PR effectively unexecuted by test coverage.

Suggested fix:

const afterPack = require('../scripts/after-pack.js');
await afterPack({ ...fixtureContext });
expect(fs.existsSync(path.join(appOutDir, 'resources', 'mcp', 'gui-operate-server.js'))).toBe(true);