feat(startup): embed Bun runtime in generated init script when running under Bun

[leonardoag2026-beep]

Summary

When PM2 is run under Bun (cst.IS_BUN), the pm2 startup command now embeds the Bun runtime (process.execPath) in front of the pm2 binary path — both in the copy/paste command hint and in the generated init script (%PM2_PATH%).

Without this, the init script starts the PM2 daemon with the shebang interpreter (node), which breaks cluster mode for Bun applications:

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for app.ts

Before / After

Running pm2 startup under Bun now generates:

# Before (shebang decides → daemon starts with node)
ExecStart=/path/to/pm2/bin/pm2 resurrect

# After (Bun runtime explicit → daemon starts with Bun)
ExecStart=/path/to/bun /path/to/pm2/bin/pm2 resurrect

Behavior under Node.js is unchanged (verified: ExecStart still the bare pm2 binary path).

Why this matters

Per the PM2 Bun docs: "Cluster mode follows the runtime of the PM2 daemon itself" — to load-balance a Bun app you must run PM2 with Bun (bunx --bun pm2 start app.ts -i max). If the init script boots the daemon with node, Bun cluster apps saved via pm2 save fail on reboot. This PR makes pm2 startup produce a Bun-runtime init script automatically when PM2 is running under Bun.

Also unifies the isNotRoot() hint to use the resolved pm2 binary path instead of the hardcoded 'pm2' string when --user is passed.

Testing

• pm2 startup under Node → command hint and unit unchanged (no regression)
• pm2 startup under Bun (bun bin/pm2 startup) → hint shows bun <pm2_bin>, generated systemd unit has ExecStart=/path/to/bun .../pm2/bin/pm2 resurrect (verified with a real unit generation + cleanup)
• npm run test:unit — only pre-existing flaky test exp_backoff_restart_delay.mocha.js fails (fails identically without this change; the project's own runner retries it)

Related issues: #5893, #5777, #5967 (cluster mode with Bun).

[CLAassistant]

All committers have signed the CLA.