feat: riscv64 prebuilt binaries

[gounthar]

Description of change

Adds a prebuilt binary for linux riscv64, so npm install node-llama-cpp on a RISC-V host picks up a ready-to-run binding instead of compiling llama.cpp from source.

riscv64 already builds from source today, but that needs a full C/C++ toolchain and around 30 minutes of native compile time. This brings riscv64 in line with the platforms that already ship prebuilts.

What's in here:

• New @node-llama-cpp/linux-riscv64 optional-dependency package (mirrors linux-armv7l).
• compileLLamaCpp.ts: resolve the riscv64 prebuilt module when arch === "riscv64".
• detectGlibc.ts: add the riscv64 multiarch lib path and the ld-linux-riscv64-lp64d.so* loader names.
• movePrebuiltBinariesToStandaloneModules.ts: move the linux-riscv64 build output into the standalone module.
• build.yml: a native riscv64 build leg.

A few CI notes, since the riscv64 leg is a bit different from the others:

• The build runs on a native ubuntu-24.04-riscv runner from the RISE RISC-V GitHub App. That app has to be installed on the repo for the leg to get a runner. I'm happy to help coordinate that with RISE.
• The binary is built from the x64-built dist (rolldown has no riscv64 binding yet), so the workflow splits into a dist-build job and a native binary-build job.
• The riscv64 runner needs Node.js from the unofficial-builds index (setup-node has no riscv64 binary), a retry around npm ci, ELECTRON_SKIP_BINARY_DOWNLOAD=1, and gcc-14 (recent ggml uses RVV _Float16/zvfh intrinsics that only exist in GCC 14+).

I validated this end-to-end on a fork: dist built on x64, binary compiled natively on the RISE runner, producing an ELF RISC-V llama-addon.node that passes the smoke check. The split-job CI is the part I'm least sure about fitting your conventions, so let me know if you'd rather I structured it differently.

Fixes #614

Pull-Request Checklist

• Code is up-to-date with the master branch
• npm run format to apply eslint formatting
• npm run test passes with this change
• This pull request links relevant issues as Fixes #0000
• There are new or updated unit tests validating the change (N/A: packaging and CI change, no runtime logic to unit test)
• Documentation has been updated to reflect this change (N/A)
• The new commits and pull request title follow the convention in the pull request guidelines

[giladgd]

Thanks for the PR!

Could you please provide me with instructions on how I can access a riscv64 machine to manually test this on?
In case the llama.cpp build fails for some reason then I'll need a way to investigate and fix it in a faster manner than to trigger many CI runs.

Also, would you be willing to help me maintain riscv support in node-llama-cpp in the future?

[giladgd]

We only use the electron types in the build anyway, so we can set that to always skip the binary download

[giladgd]

If we update npm will those issues go away? What do they stem from?
I'd prefer solving the issues from the root, since if this workaround stops working I won't know what to do or how to even approach solving this

[giladgd]

Maybe updating to actions/setup-node@v6 would work out of the box?
Maybe some config option on it would solve the issue so we don't have to run a custom node installation step?