GeezerVison

Cause

A JS function marshalled as a block cached its BlockWrapper in the per-object slot tns::SetValue/tns::GetValue uses, and that is the same slot interop.FunctionReference keeps its FunctionReferenceWrapper in. Each use evicted the other:

• FunctionReference, then block: the FunctionReferenceWrapper leaked, along with any trampoline it had cached. A later function pointer marshal found a BlockWrapper and hit tns::Assert(false) in Interop::WriteValue.
• Block, then FunctionReference: the block cache stopped hitting, and every block marshal after that built a new block.

Fix

• The JS block cache now lives in its own private slot on the function (tns::{Set,Get,Delete}JSBlockWrapper, private key jsBlock). The function's own wrapper slot is left alone.
• The ownership rule from fix(runtime): never revive a JS block whose dispose has started #500/fix(runtime): free a JS block's wrapper only once its isolate's teardown is done #501 is unchanged. Interop::JSBlock owns its BlockWrapper and always deletes it in dispose. It clears the cache slot only while that slot still holds its own wrapper, and still under the isolate pin and Locker. A JS block's wrapper never sits in the slot ObjectManager::DisposeValue reads, so teardown and GC never touch it. Cache hits still go through TryRetainJSBlock.
• interop.handleof(fn) returns a FunctionReference's trampoline once one exists. Otherwise it returns the live cached block, and otherwise it throws as before. interop.sizeof of a function with a cached block still reports pointer size.
• A second new interop.FunctionReference(fn) on the same function keeps the existing wrapper and trampoline instead of leaking them.
• A function pointer argument that is not a Pointer, a native function pointer or a FunctionReference now throws a JS error instead of asserting.

Tests

FunctionReferenceBlockTests.js (new, committed first; on main it aborts on the assert) covers:

• FunctionReference, then block, then function pointer;
• function pointer, then block, then function pointer;
• block, then FunctionReference, then block, with interop.handleof returning the same block throughout;
• handleof precedence once a trampoline exists;
• a repeated interop.FunctionReference;
• the thrown error for a plain function;
• collection of functions that were both kinds;
• a worker torn down while native code still holds the block of a FunctionReference that has a trampoline.

The existing "JS block outliving its worker" specs still test what they describe: a block outliving, or released by, its worker's teardown while the function is FunctionReference-registered. Teardown now disposes the function's FunctionReferenceWrapper, and the block's own dispose frees the block wrapper. blockTeardownReleaseWorker.js's comment is updated to match.

Suite (iOS 26.3.1 simulator):

• plain: 1762 specs, 0 failures, 11 skipped
• ASan: 1762 specs, 0 failures, 16 skipped

Fixes #503