Constant propagation misses values that only become known after stack de-aliasing

Version and Platform (required):

• Binary Ninja Version: 5.4.9793-dev Ultimate, 12373795
• OS: macOS 26.5.1
• CPU Architecture: arm64

Steps To Reproduce:

1. Download nova guard works curiously and open the included .bndb.
2. Go to 0x3b698fde in HLIL:

  40 @ 3b698fde  r9.b = *(arg4 + 4 + rdi_1 + 0x6f3b9513)

3. Hover over rdi_1 and note that it reports to have a constant value of -0x6f3b9513, yet the constant is not propagated and the resulting expression is not simplified.

Additional Information:
If I explicitly set the value of rdi_1 to -0x6f3b9513 prior to 0x3b698fde then it is propagated and simplified as expected:

  35 @ 3b698fde  ASSERT(rdi_1, ConstantValue: 0xffffffff90c46aed)
  36 @ 3b698fde  r9.b = *(arg4 + 4)

It also simplifies other uses of rdi_1 later in the function.

This appears to be a consequence of the value of rdi being most recently modified via a partial field access:

3b76597e  and     dil, byte [rsp+rdi-0x6f3b9515 {var_8+0x2}]

which ends up in MLIL as:

   8 @ 3b76597e  rdi.dil = 0x17 & var_8:2.b

If I NOP the instruction at 0x3b76597e, then the value of rdi is constant propagated. It looks like the partial write is not resolved until after the constant propagation has been performed. This means the value of rdi is not known when constant propagation is performed, and so it is left as a variable.

Start by opening the reported .bndb and inspecting HLIL at 0x3b698fde alongside MLIL around the partial write at 0x3b76597e. Compare propagation with and without that instruction, then trace the stack de-aliasing and constant-propagation stages involved. Done means the known value of rdi_1 is propagated and the resulting expression is simplified without manually setting the value.