[Bug]: OpenCode provider update can leave the global Windows CLI without a working command

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. On Windows, start with a working global OpenCode npm installation. opencode --version returned 1.17.11 before the update activity.
2. Start T3 Code Alpha 0.0.28 and allow its OpenCode provider startup/update flow to run.
3. After the provider refresh, run opencode --version again and inspect %APPDATA%\npm plus %APPDATA%\npm\node_modules.
4. Observe that the normal OpenCode shims are missing and T3 reports OpenCode as not installed or not on PATH.

I cannot prove conclusively that T3 produced the malformed upstream 1.18.4 package, but the breakage occurred during the provider update/startup sequence and T3 did not preserve or restore the previously working command.

Expected behavior

A provider CLI update should be atomic. T3 should keep the previous working OpenCode command until the new executable has been installed and successfully validated with a version/startup probe. If validation fails, it should roll back automatically and report the update error without damaging the user's global CLI.

Actual behavior

The normal %APPDATA%\npm\opencode, opencode.cmd, and opencode.ps1 shims disappeared. Only temporary dot-prefixed shim files remained, including names similar to .opencode-*.

The new opencode-ai 1.18.4 package contained a 479-byte bin\opencode.exe that was actually batch-script text rather than a Windows PE executable. The nested 1.18.4 Windows x64 executables were rejected by Windows as invalid applications.

The previous package was preserved under a temporary directory such as .opencode-ai-*. Its nested OpenCode 1.17.11 Windows binary still ran correctly. T3 nevertheless reported OpenCode as unavailable until I manually restored a shim.

Impact

Major degradation or frequent failure

Version or commit

T3 Code Alpha 0.0.28; attempted OpenCode package 1.18.4; last working OpenCode 1.17.11

Environment

Windows 11 24H2 build 26100.8875, AMD64; T3 desktop 0.0.28 x64; Node.js 24.15.0; npm global directory at %APPDATA%\npm.

Logs or stack traces

Initial provider result:
OpenCode CLI (`opencode`) is not installed or not on PATH.

Earlier startup result with the working binary:
Timed out waiting for OpenCode server start after 5000ms.

Broken package observations:
- %APPDATA%\npm\node_modules\opencode-ai\bin\opencode.exe: 479 bytes, batch-script text
- normal npm command shims missing
- only dot-prefixed temporary shims remained
- preserved previous package under %APPDATA%\npm\node_modules\.opencode-ai-*

After restoring the 1.17.11 shim and allowing a longer startup timeout, T3 reported:
Installed: true
Version: 1.17.11
Status: ready
Auth: authenticated
Message: 5 upstream providers connected through OpenCode.

Screenshots, recordings, or supporting files

No response

Workaround

I created %APPDATA%\npm\opencode.cmd pointing to the preserved nested OpenCode 1.17.11 Windows executable. opencode --version then returned 1.17.11, and T3 detected the provider as ready/authenticated. The updater should perform this rollback automatically when the replacement command fails validation.

Start in the apps/server OpenCode provider startup and update flow, then reproduce the Windows global CLI update using the reported package and shim paths. Done means the existing command remains usable until replacement validation succeeds, with automatic rollback and an update error when validation fails.