Add MAX_BUILD_THREADS setting

[mkaoudis]

Summary

• add one opt-in MAX_BUILD_THREADS setting across Make targets, Cargo updater builds/tests, native module rebuilds, and Debian/RPM/pacman packaging
• keep the default at MAX_BUILD_THREADS=0 so existing tool defaults, MAKEFLAGS, makepkg config, and RPM macros continue to apply unless a user opts in
• avoid multiplying native-module concurrency by running electron-rebuild sequentially when MAX_BUILD_THREADS is nonzero while passing the requested job count to each native build
• document the setting and add smoke coverage for thread propagation, default behavior, and override precedence

Review order

This PR should be reviewed after #322 and #323. Its code change is independent, but current CI has two unrelated upstream-drift failures: Nix pin drift addressed by #322, and required fast-mode upstream patch drift addressed by #323. After those land, this PR should be rebased or rerun before moving out of draft.

User-visible behavior

• Existing builds keep their current behavior by default because MAX_BUILD_THREADS defaults to 0.
• Users can opt in with commands such as MAX_BUILD_THREADS=8 make build-app-fresh, MAX_BUILD_THREADS=8 make package, or MAX_BUILD_THREADS=8 make install-native.
• For supported phases, a nonzero MAX_BUILD_THREADS value is the requested per-phase worker count. It also overrides inherited MAKEFLAGS for controlled make-backed subprocesses.
• RPM builders can still set RPM_BINARY_PAYLOAD directly when they need exact payload flags instead of the MAX_BUILD_THREADS-derived zstd thread setting.

Existing configurability check

• origin/main had no first-class Make/script setting for native build parallelism across app rebuilds and package builders
• tool-specific escape hatches exist, including Cargo jobs, RPM payload flags, dpkg-deb threads, makepkg config, and MAKEFLAGS, but they were not wired into one repo-level knob for this flow
• MAX_BUILD_THREADS=0 preserves those existing escape hatches; nonzero MAX_BUILD_THREADS opts into the new repo-level behavior

Source of truth

• Makefile
• scripts/lib/native-modules.sh
• scripts/build-deb.sh
• scripts/build-rpm.sh
• scripts/build-pacman.sh
• README.md
• tests/scripts_smoke.sh

Validation

• bash -n scripts/build-deb.sh scripts/build-rpm.sh scripts/build-pacman.sh scripts/lib/native-modules.sh
• bash tests/scripts_smoke.sh
• git diff --check
• make -n PACKAGE_WITH_UPDATER=0 rpm
• make -n MAX_BUILD_THREADS=8 PACKAGE_WITH_UPDATER=0 rpm
• make -n MAX_BUILD_THREADS=0 PACKAGE_WITH_UPDATER=0 rpm
• make -n MAX_BUILD_THREADS= PACKAGE_WITH_UPDATER=0 rpm
• make -n MAX_BUILD_THREADS=8 PACKAGE_WITH_UPDATER=0 check

CI note

• Current package CI has Debian/RPM/pacman packaging and Rust/smoke tests passing on the latest push.
• Nix Package Builds is failing in validate-nix-pins.sh with an upstream DMG app-version pin mismatch: expected 26.519.81530, got 26.519.41501. That happens before these build-thread changes are exercised and is addressed by fix(ci): tolerate upstream DMG rollout in PR Nix checks #322.
• The separate upstream-DMG build workflow has failed on this branch after installation during required patch validation for linux-fast-mode-model-guard because the current upstream DMG no longer matches that existing patch insertion point. That is addressed by fix(webview): handle fast-mode guard bundle drift #323.