Guard dlopen/dlsym for platforms without dynamic linking

[lancejpollard]

Adds #ifdef guards to ffi/load.c and ffi/load_dir.c so HVM4 compiles on platforms where dlopen is unavailable or restricted.

On guarded platforms, ffi_load and ffi_load_dir print an error message and exit. Primitives should be registered at compile time instead (via prim_register).

Benefits

• Enables WASM compilation. WASM has no dynamic linking, so dlopen/dlsym cause compile errors. This guard removes that barrier.
• Enables iOS and Android embedding. Both platforms restrict dlopen of code outside the app bundle apparently. Guarding it lets HVM4 compile as a static library for mobile.
• No cost on existing platforms. Desktop and server builds are unchanged. The guard only activates on restricted targets.

Changes

Two files modified, zero behavior change on existing platforms.

• ffi/load.c - Guard wraps the entire file. When __EMSCRIPTEN__ or HVM_NO_DLOPEN is defined, provides a stub ffi_load that prints an error. Otherwise, existing dlopen/dlsym code is compiled unchanged.
• ffi/load_dir.c - Same guard. Stub ffi_load_dir prints an error. The <dirent.h> and <sys/stat.h> includes (also unavailable on WASM) are inside the #else branch.

Guard trigger

#if defined(__EMSCRIPTEN__) || defined(HVM_NO_DLOPEN)
  // stub: error + exit
#else
  // existing code unchanged
#endif

• __EMSCRIPTEN__ is auto-defined by Emscripten.
• HVM_NO_DLOPEN is user-defined for other restricted targets.

Risk

Don't think any. Guard only triggers when __EMSCRIPTEN__ or HVM_NO_DLOPEN is defined. Neither is defined in normal desktop/server builds. All existing tests pass unchanged.