[Enhancement] Native Node.js bindings for mlx-lm — eliminate Python subprocess dependency

The problem
mlx-lm is currently callable from non-Python environments only via subprocess — spawnSync into mlx_lm generate, lora, convert, fuse. This works but carries real costs: process spawn overhead on every call, a Python environment that must be version-pinned and validated, and an architectural seam that is foreign to otherwise Python-free systems.
The working case
I run a production CoffeeScript/Node.js ML pipeline on Apple Silicon that does fine-tuning, LoRA adapter training, quantization, and Keyword Augmented Generation. Every part of the system is Python-free except the four mlx_lm subprocess calls. The Python environment exists solely to service those four entry points.
A technical assessment of the pipeline: https://jahbini.org/writestory.html
The request
Native Node.js N-API bindings for the four core mlx-lm operations:

generate — inference with optional adapter
lora — fine-tuning
convert — model conversion
fuse — adapter fusion

The MLX C API is already stable. Community Ruby bindings (mlx-ruby) confirm the binding pattern works. Node.js is a natural next target given V8's performance and the size of the JavaScript developer community on Apple Silicon.
Offer
I am prepared to contribute to this effort. Guidance from the core team on the preferred binding approach would be welcome.
— James A. Hinds · https://jahbini.org/ and https://jahbini.org/writestory.html

Start by reviewing the MLX C API and the community mlx-ruby binding pattern, then determine how Node.js N-API should expose the four requested operations. There are no files or tests named in the issue; done means native bindings cover generate, lora, convert, and fuse without Python subprocess calls.