fix(scenegraph): cross script-scope m as live references, only on owner transfer

[lvcabral]

Stacked on #1092 — this corrects two things about the _m_ mechanism that PR introduces. Merge #1092 first.

Both corrections come from an instrumented app run on a real device (out/xthread-m-test/), which answered three questions.

probe	device	before this PR	after
task-created node's m reaches the render thread	task / T1	task / T1 ✅	task / T1 ✅
a node stored in m, after mutating it on the render thread	changed-on-render	set-in-task ❌	changed-on-render ✅
task callFunc on a render-owned node — whose m ran?	rendezvous (callCount 2)	rendezvous ✅	rendezvous ✅

1. m holds a live reference, not a snapshot

On a device m is one associative array holding real node references — mutating a stashed node from the other thread is visible through m. Here it was a deep copy: a detached snapshot that silently stopped tracking.

Node-valued entries now cross as an address (_mref_) and resolve to this thread's own instance — live-reachability first, cross-thread registry as fallback, the ordering Task.resolveNode documents after the stale-duplicate regression. An address with no local instance is dropped with a one-shot warning rather than restored as a stale copy.

2. That was also the dominant cost

A component caching m.scene / m.parentScreen — the ordinary m.scene = m.top.getScene() idiom — dragged the entire scene tree into the payload:

m contents	before	after
scalars only	0.2 KB	0.2 KB
caches scene + parentScreen	44.4 KB	0.3 KB

44.1 KB of that was the scene tree, from a deliberately small 144-item screen.

3. _m_ only needs to travel on an ownership transfer

Since a callFunc on a node owned by another thread rendezvouses to that owner and runs against the owner's m, the copy shipped everywhere else was never read. _m_ is now opt-in, enabled only at the task → render ownership transfer — removing it from callFunc args, rendezvous responses, render-thread-queue posts, children, and nodes nested in associative arrays.

Not covered

A node reached through an array or associative array inside m (e.g. m.managers = {a: node}) still serializes as a copy. Emitting references there means threading a mode flag through jsValueOf, which is very hot and used everywhere; left out to keep this diff reviewable. Worth revisiting if it shows up in profiling.

Tests

NodeSerialization.test.js — reference emission and live resolution (a later mutation is visible through the restored m), the unresolvable-address drop, _m_ absent on non-transfer serializations, plus the existing round-trip cases updated for the opt-in flag.

Full suite green (2225), lint and prettier clean.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud