Fix bvxor A^A=0 optimization incorrectly eliminating symbolic expressions

The A^A=0 optimization in bvxor() was using equalTo() to detect when
both operands are the same expression. However, equalTo() compares
concrete values, hash, size, and level - not AST structure.

This caused a bug where two different symbolic expressions that
happened to evaluate to the same concrete value (e.g., both evaluating
to 0) would be incorrectly identified as equal, causing the optimizer
to replace the symbolic XOR with a concrete 0.

Example scenario:
- op1: symbolic register w8, evaluates to 0
- op2: bvxor(concrete_val, symbolic_result), also evaluates to 0
- bvxor(op1, op2) incorrectly returns concrete 0 instead of
  preserving the symbolic computation

This broke symbolic execution of AArch64 conditional branches where
the carry flag (computed via XOR operations in cfSub_s) would lose
its symbolic status, causing branches like b.lo to not be recognized
as symbolized.

The fix adds isSymbolized() checks to ensure the A^A=0 optimization
only applies when both operands are concrete. When either operand is
symbolic, the full XOR node is preserved to maintain symbolic
information flow.

Author: JexAmro

src/libtriton/ast/astContext.cpp

@@ -732,7 +732,10 @@ namespace triton {
           return expr2;
 
         /* Optimization: A ^ A = 0 */
-        if (expr1->equalTo(expr2))
+        /* Only apply when both operands are concrete to avoid losing symbolic information.
+         * Two different symbolic expressions may have the same concrete value temporarily,
+         * but they represent different symbolic computations that must be preserved. */
+        if (!expr1->isSymbolized() && !expr2->isSymbolized() && expr1->equalTo(expr2))
           return this->bv(0, expr1->getBitvectorSize());
       }