fix(desktop): complete setup for standard Windows users

[davidmckayv]

What this changes

Launching OpenBot as a standard Windows user failed during setup because Get-WindowsOptionalFeature requires elevation. Read WSL and Virtual Machine Platform state through Win32_OptionalFeature, and recognize modern WSL installations through WslService. Unknown or unreadable states still produce detection errors, and missing prerequisites retain their existing setup guidance.

Windows CI now runs the native setup probe under a temporary Users-only account with its own loaded profile. It selects the exact executable from Cargo's build output, requires one passing test, and removes the temporary account, profile, and files afterward.

If Windows Installer returns policy rejection 1625 while installing Podman, setup now tells the user to ask an administrator to allow installation or install Podman for their account. The error retains its exit code and log path, without retrying or changing Windows policy.

Setup also recognizes an existing stopped default Podman machine. Podman's quiet output appends * to the default machine name, so the previous exact comparison missed openbot* and attempted duplicate initialization. Detection now reads the raw Name from JSON output; unreadable output remains an error.

A fresh Windows account also reached container startup and migrations but could not start the host API because Bun was absent. Setup now acquires the repository-pinned Bun 1.3.14 runtime in the current user's OpenBot folder using a pinned SHA256, extracts only the expected executable, checks its version, and passes its absolute path to dependency installation and host startup. Existing Bun installations are retained; download, extraction, and runtime failures preserve their diagnostics.

Fixes FOR-307

Where it runs

Prerequisite detection runs in the local Windows desktop process, and machine detection runs during desktop engine setup. CI creates a temporary local account and profile, then removes them after the test. There is no new server state, cross-process serialization, browser fan-out, listener, port, or schedule; a second server replica behaves as before.

Boundary and audit

The prerequisite probes are read-only. Server gateway calls, authorization, client trust, and audit events are unchanged.

Changelog

No changelog entry: this changes desktop prerequisite and engine detection, installation guidance, and CI coverage; an already-running server deployment behaves the same.

Proof

• Head e4c5062b: CI has 19 successful checks, 3 skipped, no failures or pending checks. Includes the native Windows prerequisite test under a real Users-only account.
• Local verification passed: 581 Rust tests (three existing live tests ignored), formatting, all-target compilation, Clippy with warnings denied, PowerShell parsing, actionlint, and diff hygiene. Focused regressions cover prerequisite states, MSI policy guidance, stopped default-machine detection, and verified Bun acquisition/error paths.
• Installed the final NSIS build as the actual OpenBotStandard Users-only account in its own AppData profile, and verified that the desktop process was not elevated. The original app reproduced the reported elevation error; this build passed the prerequisite checks.
• Actual app setup installed Podman 6.1.1 and Compose 5.5.1 for that user, found and started its stopped default engine, downloaded deployment v0.0.11, started containers, and applied migrations. It automatically downloaded the checksum-matching Bun 1.3.14 runtime, installed dependencies, and started the host API, worker, and desktop UI.
• Browser and GenUI passed in the actual Windows desktop app using the existing OpenAI API key. A prompt typed into the LangGraph channel produced a real computer_navigate call to https://example.com, returning Example Domain, and a real showLineChart call with Jan=120, Feb=180, Mar=240. Visually inspected screenshots show the actual page in the app's expanded assistant screen and the rendered chart titled Windows standard-user check. This is supported by persisted tool calls/results, not just the assistant's claim.
• Screenshots are attached to FOR-307: Windows standard user: actual browser page and Windows standard user: rendered GenUI line chart. Acceptance turn: 55569917-dab5-857a-bfe3-9324b633d3d5, agent picked-harness.

Validation environment: AWS Windows Server 2022. Its default DisableMSI=1 policy blocked unmanaged per-user MSI installation; the test VM policy was temporarily set to 0 and restored immediately after prerequisite installation. OpenBot does not change that policy and now explains policy rejection 1625. After the test harness lost its generated account password, the task-owned account was recovered and a fresh configuration root was used with the same installed build and already-validated engine/runtime. OpenAI credentials were entered through the real setup UI. The earlier Qwen refusal and failed automated prompt submission were superseded by the successful OpenAI turn; no speculative product fix was added for those harness/model failures.

AWS validation instance confirmed stopped after evidence capture. PR is ready for review; no merge performed.

[linear-code]

FOR-307