Fix GH-21368 crash: runtime orig_handler lookup in escape_if_undef

[iliaal]

Follow-up to #21368.

@vibbow reported an access violation in zend_jit_escape_if_undef on
PHP 8.5.5 VS17 x64 NTS (Windows + IIS + FastCGI), crashing at the fix
I introduced in #21368:

FAILURE_BUCKET_ID: INVALID_POINTER_READ_c0000005_php8.dll!zend_jit_escape_if_undef
FAULTING_SOURCE_LINE_NUMBER: 7980

The crashing instruction is mov rcx, [rax+rcx*8+0xD0], reading 0xD0
from a heap address that isn't mapped. On 64-bit NTS that offset
corresponds to zend_op_array->reserved[zend_func_info_rid], which is
what ZEND_FUNC_INFO(op_array) expands to.

Root cause

#21368 dispatched to orig_handler via a compile-time load computed
from exit_info->op_array. That pointer is set at parent-trace compile
time from JIT_G(current_frame)->func, and can become stale by the time
a side trace compiles for that exit. Long-lived FastCGI workers with
many trace invalidation/recompile cycles match the observed failure
pattern.

Fix

Keep compile-time dispatch but resolve orig_handler against
jit->current_op_array instead of the parent's exit_info:

• On the side-trace compile path (the crash path),
  zend_jit_trace_start already sets jit->current_op_array to
  trace_buffer->op_array, which is freshly captured for the current
  compilation and doesn't depend on the parent's stale pointer.
• On the zend_jit_trace_exit_to_vm path, zend_jit_deoptimizer_start
  leaves current_op_array unset, so it is now set from
  exit_info->op_array there.

This drops the op_array parameter added to zend_jit_escape_if_undef
in #21368.

Verification

gh21267.phpt and gh21267_blacklist.phpt both pass. The original
infinite-loop fix is preserved.

Reproducer

I couldn't build a native Linux reproducer for the stale-pointer
scenario through synthetic stress. @vibbow can reproduce reliably on
IIS+FastCGI and will validate the fix once a Windows build is
available.

[dstogov]

It would be great to understand where the failure comes from.
If we somehow have an inconsistent exit_info->op_array we may get troubles in other places.

As I see, JIT_G(current_frame) is always set during trace compilation (it can't be NULL) , so this part of deduction can not be the reason of the failure.

The fix generates more expensive JIT code that performs run-time resolution, I believe it should be possible to make this resolution at compile time.

[vibbow]

I can reproduce this bug consistently. If somone can help compile a Windows version, I can test this fix

[iliaal]

1. JIT_G(current_frame) is allocated at zend_jit_trace.c:1428 before any
   exit-point creation, so the NULL hypothesis in my PR description was
   wrong. Updated the description.

2. The crash fits a stale exit_info->op_array, not a NULL one: rax+0xD0
   on an unmapped page, long-lived IIS+FastCGI worker. If this pointer
   can go stale, it's a broader invariant concern (zend_jit_dump_exit_info
   is the only other direct consumer today). I haven't yet pinned down
   the concrete path by which op_array is freed while traces referencing
   it survive.

3. Reworked the fix to keep compile-time dispatch:

   • zend_jit_escape_if_undef now uses jit->current_op_array for the
     ZEND_FUNC_INFO lookup (back to your original approach).
   • On the side-trace compile path (the actual crash path),
     zend_jit_trace_start sets jit->current_op_array to
     trace_buffer->op_array, which is freshly captured for this
     compilation and doesn't rely on the parent's possibly stale
     exit_info.
   • On the zend_jit_trace_exit_to_vm path, zend_jit_deoptimizer_start
     leaves current_op_array unset, so I set it from exit_info->op_array
     before the deopt call.

PR updated.