Potential regex compilation failure or mismatch with variable-length lookbehind in PCRE patterns

Summary
I am experiencing issues when using regular expressions containing variable-length lookbehind assertions (e.g., (?<!.(?:target|origin).{0,20})\bhaving\b) in ModSecurity v3. The pattern fails to match as expected, likely due to limitations in the underlying PCRE library integration or configuration within src/utils/regex.cc.

Steps to Reproduce
Create a SecRule using a variable-length lookbehind:

SecRule ARGS "@rx (?<!.(?:target|origin).{0,20})\bhaving\b" "id:12345,phase:2,deny,status:403"
Send a request with a payload that should match (e.g., ?data=select having count).

Observe that the rule is not triggered.

Actual Behavior
The regex fails to match the input. In some environments, no explicit compilation error is shown in the debug log, leading to "silent failure" where the rule is simply ignored.

Expected Behavior
The regex should either:

Match the input if the linked PCRE library (PCRE2 10.30+) supports variable-length lookbehind.

Provide a clear compilation error in the ModSecurity log indicating that the pattern is unsupported by the current PCRE version.

Technical Context
Looking at src/utils/regex.cc, ModSecurity wraps PCRE/PCRE2. However:

Most PCRE1 versions (still common in many distros) strictly forbid non-fixed-width lookbehind (errors like lookbehind assertion is not fixed length).

If ModSecurity is compiled with PCRE2, it should theoretically support this, but the implementation may not be passing the necessary JIT or match options to handle complex lookbehind depth.

Start by reproducing the SecRule example and then inspect src/utils/regex.cc, focusing on how ModSecurity wraps PCRE and PCRE2 compilation and matching. Compare behavior for unsupported variable-length lookbehind and supported configurations; done means the pattern matches when supported or produces a clear compilation error when it is not.