[scheduled-gate:gc-root-dominance.yml] GC Root Dominance is failing on main

[github-actions]

GC Root Dominance has a completed red post-merge run.

Current failure

• Run: 35490425701
• Head: dd00a00305bca364d2a04ae20547efad94612424
• Trigger: schedule

Failing rows

• gc-root-dominance / POLL_CAPABLE_RUNTIME entries must name real runtime symbols
• gc-root-dominance-statepoints / POLL_CAPABLE_RUNTIME entries must name real runtime symbols

Delta from the previous failed run

Previous failure: 91a566c8af52

New failing rows:

• None.

Rows that recovered:

• None.

Last green main result

fd4bcbe64705

Maintained automatically by gate-failure-watch.yml for gc-root-dominance.yml. Repeated failures update this issue; the next green run closes it.

[proggeramlug]

Fixed by #9929, landed on main via merge train #9939. The train merged as its own branch, so the close-keyword never fired — closing manually, verified on main.

[github-actions]

Green again at 1a9c0de6cb79; closing automatically.

[proggeramlug]

Diagnosis of the current red run (scheduled run 34755757397 on 820cf76729; also red at 8a058e2053):

1. The job stops before the corpus is checked. python3 scripts/gc_root_dominance_check.py --audit-poll-capable exits 2:

   error: POLL_CAPABLE_RUNTIME entries that name no runtime symbol:
     js_string_replace_all_regex_fn
     js_string_replace_regex_fn
   

   Both symbols disappeared when Perex became the only regex engine (Make Perex the runtime's only regular-expression engine #10142, merge train Merge train 170: #10142 #10146). Per the audit's own message, the fix is to replace them with the symbols codegen now emits for a callback replace/replaceAll, not just delete them.

2. Behind that, the corpus is not clean. Running scripts/gc_root_dominance_corpus.sh <out> --lowering shadow and then gc_root_dominance_check.py <out> locally (macOS arm64) gives 2 violations, both non-moving:

   test_gap_gc_regexp_receiver_rooting__...ts.ll::perry_fn_test_gap_gc_regexp_receiver_rooting_ts__run
     alloc  : call i64 @js_regexp_site_test_new(...)
     bind   : slot 1  call void @js_shadow_slot_bind(i32 1, ...)
     between: js_regexp_site_test_get_method
     MOVING : no
   

   I checked this is not new: compiling test-files/test_gap_gc_regexp_receiver_rooting.ts with a 9b911855f8 release compiler (PERRY_RS4GC=0 PERRY_GC_MOVING_LOOP_POLLS=1 PERRY_INLINE_SHADOW_SLOT=0 --trace llvm) reproduces the same two fingerprints. The allowlist is empty, so once step 1 is fixed this job will stay red on these until the site-test lowering binds the new receiver before js_regexp_site_test_get_method, or they are allowlisted with an issue.

(Found while validating a merge train; neither finding is caused by that train.)