Managed Node runtime cannot be replaced when the bundled binary will not execute #7152

Describe the bug

Buzz Desktop cannot use a packager-supplied Node.js runtime for npm-backed ACP adapters. On NixOS, Buzz downloads the official Node.js tarball successfully, but that generic ELF cannot run because it expects /lib64/ld-linux-x86-64.so.2 and shared libraries outside the Nix store. The UI then reports a readiness failure and suggests checking the network or app-data permissions, even though download, checksum verification, extraction, and permissions all succeeded.

Steps to reproduce

1. Run Buzz Desktop on NixOS without programs.nix-ld.
2. Remove any existing private runtime under ~/.local/share/Buzz/runtimes/node.
3. Open Settings, then Agents.
4. Install an npm-backed ACP adapter such as Codex ACP.
5. Buzz downloads node-v24.18.0-linux-x64.tar.gz, then reports that the managed Node.js runtime did not pass readiness after install.

Expected behavior

Packagers that already provide Node.js 24 should have a declarative way to point Buzz at that trusted runtime. An explicitly configured but invalid runtime should fail with a specific error and should not fall back to the downloaded tarball or an arbitrary executable from PATH.

Version and platform

• Buzz version: 0.5.20
• OS: NixOS 26.11, x86_64
• Packaged Node.js: 24.19.0

Logs / additional context

The downloaded binary exits 127 through NixOS stub-ld. Its ELF interpreter is /lib64/ld-linux-x86-64.so.2, and ldd also reports a missing libstdc++.so.6. Buzz currently builds only its private versioned runtime path and requires node --version to equal v24.18.0, so substituting nixpkgs nodejs_24 is not supported either.

I propose an opt-in BUZZ_NODE_BIN_DIR setting. It would accept an absolute directory containing executable node and npm, require a well-formed Node 24 version, and bypass the download only when explicitly set. Buzz's own SHA-pinned runtime would keep its exact v24.18.0 check. With the variable unset, behavior on macOS, Windows, and supported Linux systems would not change.

This is related to the portability problem in #2604, but it does not fix that AppImage issue. Packaging work in #3734 and #6924 could consume the new setting.