[LHagfoss]

What

Linux installs still selected AppImage after the smaller system-WebKitGTK archive shipped, and downloaded a separate CLI engine. Prefer the verified archive when system WebKitGTK 4.1 is available, install the app in a writable stable directory, and link the CLI to its engine. A server installed from this app uses that same engine through the existing non-AppImage service path.

Add explicit --system-webkit and --appimage choices, check actual shared-library dependencies before installation, and retain AppImage fallback when WebKitGTK or an older release archive is unavailable. Existing AppImage and service files stay intact, with migration instructions, so running processes and service definitions remain valid.

Changelog

Use smaller Linux desktop downloads when system WebKitGTK is installed and share the app engine with the CLI.

Testing

• Passed bash -n scripts/install.sh, git diff --check, and bash scripts/test-ci-relevant-changes.sh.
• Passed eight isolated integration tests with local checksum manifests: shared CLI, reinstall, no-CLI preservation, missing WebKitGTK and transitive libraries, checksum rejection, incomplete archive rejection, explicit AppImage, and older-release fallback. Added these tests to CI.
• Downloaded the actual v1.36.3 system-WebKitGTK archive on Arch and verified SHA256SUMS. Its only unresolved shared libraries here are WebKitGTK and JavaScriptCore. Actual-host installer preflight stops before mutation with the package-install command.
• After the user installed WebKitGTK, passed a native desktop smoke test under Xvfb with isolated HOME/config/runtime and a separate D-Bus session; inspected the rendered onboarding screenshot. Confirmed both WebKit libraries resolve to /usr/lib. No credentials were copied and no model turn was run.
• Installed the verified release through the candidate installer on the actual Arch host. Confirmed CLI symlink and version, updated the systemd service to the shared engine, restarted it while idle, and verified server/gateway healthy with no reported problems. Removed the obsolete service engine only after checking the running executable and matching its old bytes against the retained AppImage engine. The old AppImage stays until the current window is closed and the new launcher is verified.
• No compiler profile changes: binary-level optimization needs comparative build and performance measurements.