[Bug]: Bundled t3-resource-monitor ships mode 0644, so native process telemetry never starts on Linux/macOS

What happened

On Linux, t3 serve (headless systemd user service, t3@0.0.33) logs:

Resource monitor binary at '.../node_modules/t3/dist/resource-monitor/linux-x64/t3-resource-monitor' is not executable.
Failed to read native resource telemetry history

The native process monitor never starts. The server itself is fine.

The file on disk is a valid ELF PIE (t3-resource-monitor 0.1.0, sysinfo), but npm extracted it as -rw-rw-r-- (0644 / 0664). T3's resolver then fails closed:

// ResourceMonitorBinary.resolve, non-Windows
if ((stat.mode & 73) === 0) // 0o111
  fail ResourceMonitorBinaryNotExecutable

It does not chmod the sidecar.

Root cause

This is in the published t3 tarball, not local umask or a noexec mount. From registry.npmjs.org:

t3@0.0.33
  0644  package/dist/resource-monitor/darwin-arm64/t3-resource-monitor
  0644  package/dist/resource-monitor/darwin-x64/t3-resource-monitor
  0644  package/dist/resource-monitor/linux-x64/t3-resource-monitor
  0644  package/dist/resource-monitor/win32-x64/t3-resource-monitor.exe
  0755  package/dist/bin.mjs

Same modes in t3@0.0.34-nightly.20260820.1146 (checked today). bin.mjs is executable because it is the npm bin entry; the Rust sidecars are copied into dist/resource-monitor/<platform>-<arch>/ without +x before npm pack.

Windows skips the mode check, so this specifically breaks Unix t3 serve / CLI installs. Desktop artifact builds that stage resources/resource-monitor/t3-resource-monitor separately may not hit it.

Related class of bug: #4924 (node-pty spawn-helper also published 0644). This one is T3's own binary, not node-pty.

Workaround

find "$T3CODE_HOME/runtime/versions" -type f -name t3-resource-monitor -exec chmod +x {} +
# then restart t3 serve

Must be repeated after every runtime install/update, because a fresh extraction restores 0644.

Suggested fix

1. chmod +x the Unix sidecars when CLI release jobs copy them into apps/server/dist/resource-monitor/<platform>-<arch>/ (and assert mode in CI on the packed tarball).
2. Defensive: if ResourceMonitorBinary.resolve finds a non-executable Unix sidecar that T3 owns, chmod it (or spawn via an explicit interpreter) instead of staying unavailable. Same idea as the startup chmod suggested on #4924.

Environment

• Linux x86_64 (glibc), Node v22.23.2
• t3@0.0.33 via ~/.t3/runtime/versions/0.0.33 (t3 serve)
• Also verified the tarball modes for 0.0.34-nightly.20260820.1146

Start with the CLI release jobs that copy binaries into apps/server/dist/resource-monitor/-/ and inspect ResourceMonitorBinary.resolve's Unix mode check. Reproduce the package contents with the published tarball, then verify that Unix sidecars retain executable modes in the packed artifact and that CI asserts those modes; assess the defensive resolver behavior separately.