fix(linux): fall back to --no-sandbox when user namespaces are restricted

[xAlcahest]

Summary

Ubuntu 23.10+ enables kernel.apparmor_restrict_unprivileged_userns=1 by default, which denies the user namespaces Chromium's sandbox needs to any process without an AppArmor profile. Electron then falls back to the setuid chrome-sandbox helper, which inside an AppImage FUSE mount can never be root-owned with mode 4755, so the app aborts at launch (electron/electron#41066). deb/rpm installs are unaffected because after-install.sh already sets the SUID bit.

The launcher script generated by wrapLinuxBinary in scripts/afterPack.js now checks at startup: if chrome-sandbox next to the binary is not setuid root and unshare --user --map-root-user true fails, it starts with --no-sandbox and prints a notice to stderr. This is the same probe electron-builder ships in AppRun since 26.9 (electron-userland/electron-builder#9590), which we don't get on 26.4 with the default AppImage toolset. The uid mapping in the probe matters: on Ubuntu 24.04 namespace creation succeeds but capabilities inside are denied, so a plain unshare --user reports the sandbox as usable when it isn't. This also covers tar.gz, while deb/rpm and distros with working namespaces keep the sandbox.

Fixes #1033

Changes

• scripts/lib/linux-launcher.js: new module that generates the Linux launcher script (template moved out of afterPack.js), adding the sandbox fallback and executable name validation
• scripts/afterPack.js: wrapLinuxBinary now builds the wrapper via the new module
• test/helpers/linuxLauncherSandbox.test.js: tests for the fallback (failing probe, working namespaces, setuid helper present, unshare missing, flag ordering, name validation)