Object-op hot paths: TLS fetch density (~50% of write samples) + hot-path mutex — Phase A acceptance completion (#6759) #6809

Profiling the #6759 acceptance micros on merged main (post #6800–#6808) shows the residual object-op gap vs node is no longer shape/side-table probes — it is TLS-fetch density in the helper layers. On the write micro (9.6M dynamic writes to existing keys, ~1.6µs/op vs node ~0.8ns):

_tlv_get_addr (libdyld)            944 samples   ← ~50% of top-of-stack
pthread_mutex_lock/unlock          175 samples   ← hot-path mutex
_platform_memcmp                    71 samples   ← key compares (fine)

Phase A's acceptance criterion was _tlv_get_addr + LocalKey::with ≤2% of samples; the ENTRY points do fetch state() once (#6795/#6799), but each write then descends through helpers that re-fetch TLS independently — runtime_write_barrier_slot (GC flags + remembered set), arena state, interned_key_ptr/plan probes, mark_object_dynamic_shape_unknown, transition-cache access — multiplying to dozens of _tlv_get_addr calls per logical operation. The mutex samples want identifying too (prime suspect: the global string-intern table taken per write for plan keying).

Scope: thread the &'static RuntimeState (or a per-op context) DOWN through the object read/write helper stacks so one fetch serves the whole operation, audit the remaining non-state thread_local!s on those paths (GC flags/remembered set are the big ones), and get the intern mutex off the per-op path (thread-local intern cache or pre-interned plan keys). Measurement protocol + current baseline table: see the #6759 acceptance comment.