gc_root_dominance_check: 96 false-positive violations on #11554's template-coerce join (shadow mode follows the phi past the replacing slow edge) #11604

gc-root-dominance (scripts/gc_root_dominance_check.py over the corpus) reports 96 violations on main, all the same shape. It was seen on the labelled full-tier run of #11551 (job 108725972491), which was rebased on main 73fc6b9. #11551 doesn't touch codegen.

  alloc  : %r2975 = call double @js_jsvalue_to_string_method_box(double %r2974)
  store  : store i64 %r2983, ptr %r2178
  bind   : slot 12  call void @js_shadow_slot_bind(i32 12, ptr %r2178)
  between: js_template_string_coerce_box
  MOVING : YES via js_template_string_coerce_box
=== violations: 96   (moving-minor reachable: 96)
      96  (   96 moving)  js_jsvalue_to_string_method_box

So in template-literal lowering, the result of js_jsvalue_to_string_method_box is not rooted until after a call to js_template_string_coerce_box, which can run a moving minor. That is a dangling-root hazard: the "rooted slot holding a dangling pointer" class described in docs/src/internals/gc-rooting-invariant.md.

Suspected source: #11554 (S2, "GC-leaf fast paths for ... template coercion"), which split js_template_string_coerce_box into an inline string/SSO tag test plus the helper as the cold arm. The helper still collects, and the operand root store now lands after it. gc-root-dominance runs only in the full tier and label-gated workflows, so #11554's own PR run never executed it.

Fix: the root store must dominate the coerce-box call, or the operand must be re-derived after it. Then gc-root-dominance must be back to 0 violations, since the allowlist is empty by policy.