riveLock() / riveUnlock() not exported — missing EXPORT macro in definition

Description

riveLock() and riveUnlock() are declared with PLUGIN_API in the public header but defined without the EXPORT macro in the implementation file. This means they lack attribute((visibility("default"))) on non-Windows/non-Emscripten platforms and are not reliably visible via dlsym.

Header (native/include/rive_native/external.hpp , lines 83–84):

PLUGIN_API void riveLock();
PLUGIN_API void riveUnlock();

Implementation ( native/src/pls_binding.mm, lines 260–261):

// Missing EXPORT — plain C++ linkage, no visibility attribute
void riveLock() { g_mutex.lock(); }
void riveUnlock() { g_mutex.unlock(); }

Compare with other functions in the same file that correctly use EXPORT:

EXPORT void* nativeTexture(MetalTextureRenderer* renderer) { ... }
EXPORT bool clear(MetalTextureRenderer* renderer, ...) { ... }
EXPORT void destroyRiveRenderer(void* renderer) { ... }

Impact
External consumers that load rive_native as a shared library (e.g., a separate CocoaPod/framework) cannot resolve these symbols via dlsym(RTLD_DEFAULT, "riveLock") — it returns NULL. This prevents third-party code from acquiring the global mutex before calling renderer functions like nativeTexture(), making it impossible to safely serialize access across threads.

Rive's own plugin ( rive_native_plugin.mm ) is unaffected because it links directly within the same compilation unit.

Suggested Fix

-void riveLock() { g_mutex.lock(); }
-void riveUnlock() { g_mutex.unlock(); }
+EXPORT void riveLock() { g_mutex.lock(); }
+EXPORT void riveUnlock() { g_mutex.unlock(); }

Environment
Package: rive_native 0.1.2
Platform: macOS (ARM64), likely affects iOS and other non-Windows platforms
File: native/src/pls_binding.mm, lines 260–261

Start with the declarations in native/include/rive_native/external.hpp and the definitions in native/src/pls_binding.mm around lines 260–261, comparing them with the nearby exported functions. Confirm that riveLock and riveUnlock are visible to external consumers through dlsym, and consider the issue complete when both symbols resolve on the affected native platforms.