[php-src] PR #24694: Report delayed OOM raised during compilation even when compilation fails

Pull Request: https://github.com/php/php-src/pull/24694 Author: srayuth089 Fixes GH-24631. A delayed OOM recorded while compiling the main script is only consumed by zend_execute_script() when zend_compile_file() returns an op_array. When compilation fails afterwards — e.g. the OOM-truncated source yields a parse error — op_array is NULL, zend_handle_delayed_oom() is never reached, and the pending EG(delayed_oom) is silently dropped: the parse error is reported instead of the real out-of-memory error. This mirrors the gap @bhaak noted for sapi/fuzzer/fuzzer-sapi.c, where the same if (op_array) guard hides a compile-time OOM. ### Fix Handle the delayed OOM right after zend_compile_file(), regardless of whether an op_array was produced. A pending exception at that point (the parse error from the truncated source) is a downstream artifact of the OOM, so it is discarded in favour of the OOM, which is the real error. ### Reproduce ```sh php -n -r 'file_put_contents("oom.php", "<?php\n\$a = \x27" . str_repeat("A", 3 << 19) . "\x27;\n)\n");' php -n -d memory_limit=4M oom.php ``` Before: ``` Parse error: Unmatched ')' in oom.php on line 3 ``` After: ``` Fatal error: Allowed memory size of 4194304 bytes exhausted (tried to allocate 2097152 bytes) in oom.php on line 2 ``` ### Testing - New regression test Zend/tests/gh24631.phpt. - Verified on master (8.7.0-dev): case A (huge literal + stray )) now reports only the OOM; a clean huge literal still reports the OOM; an ordinary parse error (no OOM) is unaffected. - Full Zend/tests run: 0 failed, 0 warned (175 skipped for the minimal --disable-all --enable-cli build, 1 expected-fail). - The issue reproduces on the 8.4.27 stable release as well, not only 8.5-dev, so a backport is likely warranted.