libafl pointers getting corrupted when a harness function overflows (mac m4)

**IMPORTANT**
1. You have verified that the issue to be present in the current `main` branch

Thank you for making LibAFL better!

**Describe the bug**

I have used Libafl at main branch with commit `a2eb6ecf822e2a30839f1b698ae3640556f9507d`

cargo 1.91.1 (ea2d97820 2025-10-10)
rustup 1.28.2 (e4f3ad6f8 2025-04-28)

The target function `processVulnerableImageFromFile:` has a stack buffer overflow. When it overflows, it writes past its stack frame and corrupts memory that belongs to:

```
┌─────────────────────────────┐ High addresses
│ LibAFL's executor state │ ← gets corrupted
│ (fuzzer, state, mgr ptrs) │
├─────────────────────────────┤
│ Frida helper data │ ← gets corrupted
├─────────────────────────────┤
│ harness function │
├─────────────────────────────┤
│ processVulnerableImageFromFile │
│ [BUFFER OVERFLOW HAPPENS] │ ← overflow writes upward
│ local buffer │
└─────────────────────────────┘ Low addresses
```
attaching debugger revealed this:

```
(lldb) process attach --pid 24973
Process 24973 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1111111111111111)
frame #0: 0x0000000100a93d40 libafl_fuzzer`libafl::executors::hooks::unix::unix_signal_handler::inproc_crash_handler::hcff683bd75bb190a + 3952
libafl_fuzzer`libafl::executors::hooks::unix::unix_signal_handler::inproc_crash_handler::hcff683bd75bb190a:
-> 0x100a93d40 <+3952>: ldp q0, q1, [x23]
0x100a93d44 <+3956>: ldp q2, q3, [x23, #0x20]
0x100a93d48 <+3960>: stp q2, q3, [x0, #0x20]
0x100a93d4c <+3964>: stp q0, q1, [x0]
Target 0: (libafl_fuzzer) stopped.
Executable binary set to "/Users/vinay/research_libafl_mac_patch/libafl_fuzzer/target/release/libafl_fuzzer".
Architecture set to: arm64-apple-macosx-.
(lldb) bt
warning: could not execute support code to read Objective-C class data in the process. This may reduce the quality of type information available.

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1111111111111111)
* frame #0: 0x0000000100a93d40 libafl_fuzzer`libafl::executors::hooks::unix::unix_signal_handler::inproc_crash_handler::hcff683bd75bb190a + 3952
frame #1: 0x0000000100c003f4 libafl_fuzzer`libafl::executors::hooks::unix::unix_signal_handler::_$LT$impl$u20$exceptional..unix_signals..SignalHandler$u20$for$u20$libafl..executors..hooks..inprocess..InProcessExecutorHandlerData$GT$::handle::hfe2882b0a0512d66 + 100
frame #2: 0x0000000100b05b98 libafl_fuzzer`exceptional::unix_signals::handle_signal::h7138974ceaf314e5 + 132
frame #3: 0x0000000100da0150 libafl_fuzzer`gum_exceptor_backend_on_signal + 448
frame #4: 0x000000019456d6a4 libsystem_platform.dylib`_sigtramp + 56
frame #5: 0x000000019443ca94 libsystem_c.dylib`__abort + 164
frame #6: 0x000000019442d818 libsystem_c.dylib`__stack_chk_fail + 96
frame #7: 0x0000000102b1f65c libImageLab-ObjC.dylib`-[ImageProcessor processVulnerableImageFromFile:](self=0x0000000324a04080, _cmd="processVulnerableImageFromFile:", filePath=0x0000000000000000) at ImageProcessor.m:662:1
```

**To Reproduce**

This is my fuzzer code: https://gist.github.com/Xplo8E/cabb92c9a0b128d38856e61d2d9accbe

**Expected behavior**

The fuzzer executions increased and same after sometime, at this phase attach debugger to check the issue

```
[Testcase #1] (GLOBAL) run time: 0s, clients: 1, corpus: 35, objectives: 0, executions: 10249, exec/sec: 0.000, edges: 0.305%
(CLIENT) corpus: 35, objectives: 0, executions: 10249, exec/sec: 0.000, edges: 200/65536 (0%)
[UserStats #1] (GLOBAL) run time: 1s, clients: 1, corpus: 35, objectives: 0, executions: 19838, exec/sec: 18.52k, edges: 0.325%
(CLIENT) corpus: 35, objectives: 0, executions: 19838, exec/sec: 18.52k, edges: 213/65536 (0%)
[Testcase #1] (GLOBAL) run time: 1s, clients: 1, corpus: 36, objectives: 0, executions: 19838, exec/sec: 18.43k, edges: 0.325%
(CLIENT) corpus: 36, objectives: 0, executions: 19838, exec/sec: 18.43k, edges: 213/65536 (0%)
[Broker Heartbeat #0] (GLOBAL) run time: 31s, clients: 1, corpus: 36, objectives: 0, executions: 19838, exec/sec: 638.3, edges: 0.325%
(CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
[Broker Heartbeat #0] (GLOBAL) run time: 1m-1s, clients: 2, corpus: 36, objectives: 0, executions: 19838, exec/sec: 324.8, edges: 0.325%
(CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
[Broker Heartbeat #0] (GLOBAL) run time: 1m-31s, clients: 2, corpus: 36, objectives: 0, executions: 19838, exec/sec: 217.8, edges: 0.325%
(CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
[Broker Heartbeat #0] (GLOBAL) run time: 2m-1s, clients: 2, corpus: 36, objectives: 0, executions: 19838, exec/sec: 163.8, edges: 0.325%
(CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
[Broker Heartbeat #0] (GLOBAL) run time: 2m-31s, clients: 2, corpus: 36, objectives: 0, executions: 19838, exec/sec: 131.3, edges: 0.325%
(CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
[Broker Heartbeat #0] (GLOBAL) run time: 3m-1s, clients: 2, corpus: 36, objectives: 0, executions: 19838, exec/sec: 109.5, edges: 0.325%
(CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
[Broker Heartbeat #0] (GLOBAL) run time: 3m-31s, clients: 2, corpus: 36, objectives: 0, executions: 19838, exec/sec: 93.98, edges: 0.325%
```