fix: launch Windows desktop app on double-click; drop the .bat launcher

[HuggeK]

Problem

On Windows, double-clicking device-simulator.exe from the release zip appears to do nothing — no window opens.

Root cause: the released .exe is built with -H windowsgui (GUI subsystem, no console), and the --desktop flag defaulted to false. A double-click therefore started a hidden, headless HTTP server with no window and no console output. The Wails desktop window only appeared when --desktop was passed — which is why the release shipped a Device-Simulator.bat whose only job was to add that flag. That .bat workaround is fragile: antivirus false-positives, a console flash, and it's easy to misplace.

Fix

Gate the --desktop default on the desktop build tag, via two small files:

• cmd/simulator/desktop_mode_on.go (//go:build desktop) → defaultDesktopMode = true
• cmd/simulator/desktop_mode_off.go (//go:build !desktop) → defaultDesktopMode = false

The desktop release builds (macOS/Linux/Windows) already compile with -tags "desktop,production", so they now default to desktop mode — double-clicking the executable opens the native window, no .bat needed. The Docker image and the *-server Makefile targets omit the tag and keep defaulting to the headless HTTP server. WAILS_DESKTOP now also accepts 0 to force headless (mirroring 1).

Removed the generated Device-Simulator.bat step from the Windows CI build.

Headless mode (now documented)

The same executable still runs headless:

device-simulator.exe --desktop=false

then browse to http://localhost:8762. Documented in the README, the release notes, and CLAUDE.md. (Because the released .exe is a GUI build it produces no console output and Ctrl+C won't stop it — control it from the web dashboard, or use Docker / make build-windows-server for console logs.)

Changes

• cmd/simulator/main.go — flag default is now defaultDesktopMode; WAILS_DESKTOP handles both 0 and 1
• cmd/simulator/desktop_mode_on.go, desktop_mode_off.go — build-tag-gated default (new)
• .github/workflows/build.yml — drop .bat generation; update Windows install + headless notes
• README.md, CLAUDE.md — document double-click launch and --desktop=false headless mode

Verification

• go test ./... passes
• Default (untagged) build compiles and runs in server mode
• -tags "desktop,production" -H windowsgui build compiles (CI's exact Windows binary)
• Smoke-tested --desktop=false: serves the API/dashboard in server mode

Note for maintainers

No Wails binding regeneration and no API changes. This is a patch-level bug fix — feel free to merge with a patch: prefix to cut a release. I deliberately used a non-patch:/minor:/major: subject so this fork PR doesn't trigger the signed release pipeline (which needs secrets unavailable to forks); only the test job runs.

🤖 Generated with Claude Code

[miravoss26]

Reviewed the diff (build-tag default flip for --desktop, plus docs).

What it does: desktop release builds (compiled with the desktop tag) now default --desktop to true via a build-tag pair (desktop_mode_on.go / desktop_mode_off.go), so double-clicking the Windows .exe opens the native window without the .bat launcher. Server/Docker builds keep defaulting to headless. WAILS_DESKTOP now explicitly supports 0 to force headless (previously only 1 was handled).

Correctness: the two build-tagged files are mutually exclusive (//go:build desktop / //go:build !desktop) so there's no ambiguity at compile time. The WAILS_DESKTOP switch (1/0/anything else) reads right — env overrides flag/default either direction, matches the updated docs. Docs (CLAUDE.md, README, workflow release notes) were updated consistently with the behavior change.

Security: none — no secrets, no new deps, no new network surface, CI-workflow-only + Go flag default change.

Small note, not blocking: statusCheckRollup is empty on this PR (no CI configured to run on it), so I can't confirm the Windows build step itself still compiles clean — worth a manual build check before merge if that job doesn't trigger automatically.

Safe to merge from my read.