fix(launcher): auto-start the server so launching the app actually serves

[localai-bot]

Fixes #11673

What was happening

On macOS, launching the DMG app after the first-run install appeared to do nothing: no window, nothing listening on localhost:8080, and empty log files under ~/.localai/logs/, while running ~/.localai/bin/local-ai by hand worked fine.

Three launcher defects stacked up to produce this:

1. Nothing ever started the server. Initialize() only called StartLocalAI() when StartOnBoot was enabled, which defaults to false and whose checkbox is labeled "Start LocalAI on system boot", so nobody enables it expecting "start when the app opens". The AutoStart config field existed but was never read anywhere. The empty log files are the fingerprint: one is created on every launch, but only server output is ever written to it, and the server never spawned.
2. The welcome window disabled itself on its first showing. The "don't show this welcome window again" checkbox was initialized with the inverted value (SetChecked(*config.ShowWelcome)), and SetChecked fires the change callback, which immediately persisted ShowWelcome=false. So on relaunch the one window that could orient the user never appeared again.
3. After a fresh install completed, the server was not started either; the dialog told the user to go find a start button in the tray.

What this PR changes

• The launcher auto-starts the server when it opens (when a server binary is installed) and right after a fresh install completes. Failures are surfaced through the systray startup-error dialog, since there is no visible window during an auto-start.
• New auto_start_server config key, default enabled, with a "Start LocalAI when the launcher opens" checkbox in Settings. The key is deliberately not the legacy auto_start: that field was never honored nor exposed in any UI, so every existing launcher.json carries an unintentional false that would keep auto-start permanently off for exactly the users hit by this bug. StartOnBoot keeps its historical force-start behavior.
• Fixed the welcome checkbox polarity, and the initial state is now applied before the change callback is attached.
• The app reported itself as version 0.0.0 in the About box (also noted in the issue): fyne package now receives --app-version, sanitized from git describe output (v4.9.0, v4.9.0-14-gabc1234, or a bare sha) down to the numeric core fyne accepts, falling back to 0.0.0 only when there is no tag.
• Docs: added a "First Launch" section to the macOS getting-started page describing the menu-bar app, the automatic server start and how to turn it off, and the WebUI URL.

Testing

The launcher package is excluded from lint and not exercised by CI, and fyne needs X11/GL headers to compile, so the suite was run in a golang:1.26 container with xorg-dev/libgl1-mesa-dev:

• New Ginkgo specs for ShouldAutoStartServer (default-on, explicit opt-out, StartOnBoot override, legacy auto_start:false ignored) and for the welcome checkbox initial state. They were written first and failed against the old behavior.
• All 41 specs pass; go vet ./cmd/launcher/... is clean.
• Also repaired two pre-existing specs that can never have passed on a clean Linux environment: Expect(config.ShowWelcome).To(BeTrue()) on a *bool, and a BuildRunArgs assertion rejecting every /tmp/-prefixed arg, which trips on Linux where the test's own tempdir lives under /tmp (it now rejects only the shared /tmp/generated and /tmp/upload server defaults it was written to guard against).
• Makefile version sanitization verified via make -s -f harness for tagged, untagged, and sha-only VERSION values.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PZ5qWPRJK4JF77NCWUsgf8