fix: make Rive data binding thread-safe on iOS & Android (#297)

[mfazekas]

Summary

Fixes the occasional crashes in #297. The Rive data-binding objects aren't thread-safe and must be driven from a single thread, but the Nitro layer accessed them from several threads with no synchronization:

• iOS — the Rive SDK plus the Obj-C RiveDataBindingViewModelInstance / C++ ViewModelInstanceRuntime caches are main-thread-only, yet they were touched from the JS thread (sync accessors), the Swift cooperative pool (every Promise.async), and the main render loop. Concurrent access corrupts those caches → the three crash stacks in the issue.
• Android — BaseHybridViewModelPropertyImpl iterated its listener map on a Dispatchers.Default flow collector while addListener/removeListener mutated it from the JS thread → ConcurrentModificationException (this is what crashed the test-harness-android CI job).

The fix

iOS — route all data-binding access through the main thread:

• MainThread.run — runs inline on main, else hops via DispatchQueue.main.sync.
• Promise.onMain — runs the work on the main thread and resolves the promise right there on the calling thread, instead of resolving it later from a background thread. Nitro's Promise has an unlocked listener list; resolving it on the spot (before Nitro attaches .then) means no background resolve can race that .then, which clears the Nitro Promise-layer races too, not just the Rive ones.
• Applied to HybridViewModelInstance, HybridViewModel, every HybridViewModel*Property, the property listener helper, and the deprecated imperative RiveView input/text-run methods (set/getNumberInputValue, set/getBooleanInputValue, triggerInput, set/getTextRunValue).

Android — BaseHybridViewModelPropertyImpl now uses a ConcurrentHashMap and iterates a toList() snapshot in onChanged, so dispatch is safe even if a callback adds/removes a listener mid-iteration.

Verification (Thread Sanitizer)

Built the iOS example with -enableThreadSanitizer YES and ran a concurrent data-binding stress (viewModelAsync + synchronous property access on the same instance). TSan reports data races on the unfixed build and none after the fix; under heavy load the unfixed build crashes, the fixed one doesn't.

On Android, the harness test hits the ConcurrentModificationException crash before the fix and passes after.

Tests

react-native-harness tests — they always pass, the sanitizer is the real assertion (unfixed runtime → race reported / crash; fixed → clean):

• example/src/__tests__/issue297.databinding.test.ts — viewModelAsync (off-main) concurrent with synchronous property access. Raise CONCURRENCY/ROUNDS to reproduce the hard crash (what took down the Android CI job).
• example/src/__tests__/issue297.hooks.test.tsx — the same bug via the public use* hooks: a live RiveView advances the state machine on the render thread while useRiveNumber churns the property (writes + addListener) on the JS thread.

example/src/reproducers/Issue297ThreadRace.tsx is a manual in-app reproducer.

Running the harness tests under Thread Sanitizer (iOS)

TSan is a compile flag, and the harness only drives a prebuilt app (it has no build step), so it can't be a harness option — it's the normal build plus one xcodebuild flag. yarn ios builds and installs the app, then the harness drives it:

cd example
yarn ios --no-packager --extra-params "-enableThreadSanitizer YES"
yarn test:harness:ios --testPathPattern issue297

--no-packager stops run-ios from starting Metro (the harness starts its own). The harness auto-targets the booted simulator (see rn-harness.config.mjs). TSan reports land in /tmp/tsan_harness.<pid>; grep for WARNING: ThreadSanitizer: data race — present on the unfixed runtime, absent after the fix.

Prefer an explicit build + install (what CI does)? Note build:ios needs --buildFolder to land in ios/build:

yarn build:ios --buildFolder build --extra-params "-enableThreadSanitizer YES"
xcrun simctl install booted ios/build/Build/Products/Debug-iphonesimulator/RiveExample.app
yarn test:harness:ios --testPathPattern issue297

Or enable Thread Sanitizer in the Xcode scheme (Run → Diagnostics) and ⌘R once to build+install.