HLIL shows deeply nested if statements with duplicated bodies that should be a single `if (a || b || c || d || e || f)`

Version and Platform (required):

• Binary Ninja Version: 5.0.7116-dev (78683157)
• OS: macOS 15.3.2
• CPU Architecture: arm64e

Bug Description:

Steps To Reproduce:

1. Open dyld shared cache from macOS 15.3.2 and load ImageIO.framework.
2. Go to ___IIOIsOOPEnabled_block_invoke and look at the HLIL in linear view.

Expected Behavior:
Readable HLIL without the duplication. With the current HLIL it's hard to tell whether the bodies of the if statements are identical without looking closely at each of them.

In MLIL you can see each of the ~20 basic blocks in this part of the function look like so:

  22 @ 18bdd2a9c  CFStringRef x0_5 = x19
  23 @ 18bdd2aa4  x0_4 = j__CFStringCompare(theString1: x0_5, theString2: &cfstr_com.apple.MessagesAirlockService, compareOptions: 0)
  24 @ 18bdd2aa8  if (x0_4 == 0) then 37 @ 0x18bdd2cb8 else 40 @ 0x18bdd2ab4

They all have a common target when the result of CFStringCompare is 0. When non-zero, they fall through to the next comparison in the sequence. This should be recognized as a single if with many conditions or'd together:

if (!CFStringCompare(…)
    || !CFStringCompare(…)
    || !CFStringCompare(…)
    || …)
    x20_1 = "disabled"
    x8_1 = "always exempt process"

Binary:
/System/Cryptexes/OS/System/Library/dyld/dyld_shared_cache_arm64e on macOS 15.3.2.

Reproduce the issue by opening the specified dyld shared cache, loading ImageIO.framework, and inspecting ___IIOIsOOPEnabled_block_invoke in HLIL linear view. Compare the roughly 20 MLIL basic blocks with the generated HLIL. Done means the repeated comparisons are represented as one conditional with ORed conditions and the shared body is shown once.