vfs: add materializeSync() for FFI consumers

[mcollina]

Native addons inside a mounted VFS already load through require(): the loader hands their bytes to an internal helper that writes them to a private image the dynamic loader can open. Libraries that open a binary by path themselves — FFI bindings that dlopen() a shared library, for example — never reach the module loader, so that route cannot help them.

This adds vfs.materializeSync(path), exposing the same mechanism as a public API:

const vfs = require('node:vfs');
const path = require('node:path');

// Paths outside a VFS pass through unchanged, so this is safe to
// call unconditionally.
const libPath = vfs.materializeSync(path.join(__dirname, 'libsqlite3.so'));
const lib = koffi.load(libPath);

• A path outside any VFS is returned unchanged: it is already openable.
• A VFS path is read and its bytes are written to a private image — an anonymous in-memory memfd on Linux (nothing touches the file system), a temporary file elsewhere — that stays loadable for the rest of the process lifetime, so the returned path can be handed to any consumer that opens it by path.
• Repeated calls with the same path return the same image. Unmounting drops the path from the cache while leaving already materialized images alive, since a consumer may still be about to open them. Retained temp files are removed at normal process exit (Windows uses the existing retained delete-on-close handles).

The C++ side reuses AddonImage (the materializer behind dlopenBinary) with a new Retain() consumption mode, exposed as materializeBinary() on the process_methods binding, with the same temp-dir write-permission check and a new ERR_VFS_MATERIALIZE_FAILED error code.

The new test simulates an FFI consumer by calling process.dlopen() on the materialized path directly — the path lies outside the VFS, so the call takes the unhooked route straight to the OS loader, exactly like an FFI library would.

Bug fix included

Writing that test exposed a pre-existing bug, fixed in the first commit: the dlopen hook installed while a VFS is mounted always forwarded its flags parameter, so a two-argument process.dlopen() call for a real file-system path reached the original implementation with undefined as the flags. That coerces to 0, which is not a valid dlopen(2) mode, and loading any addon from the real file system failed with EINVAL while a VFS was mounted.

[pipobscure]

LETM (Looks Excellent To Me 😃 )

[pipobscure]

The only question I have is whether we want to hide the detail that the path may need materializing inside ffi.load like we did for process.dlopen. There are pro & cons for both. And maybe someone that is using FFI is the kind of person good with handling this manually. However this is also the kind of thing that's easy to forget to do (especially if you don't think of VFS as an option). So hiding it inside ffi.load would eliminate this fault category.

And since node:ffi has both dlopen and dlclose we even have a good place to put it and do reference counting. Making a library Symbol.disposable can call dlclose which would decrement the counter on the path and on the last close we can delete the file. And then just cleanup leftovers atexit.