fix:Fix MIR const evaluator panic due to incompatible integer operands.

[YUZHEthefool]

错误代码让常量求值器收到了两种不兼容的整数表示。原实现默认它们一定相同，因此直接 panic；现在会先检查，不兼容时返回普通错误，避免 rust-analyzer 崩溃。
<The error code caused the constant evaluator to receive two incompatible representations of integers. The original implementation defaults that they must be the same, so it panics directly.
So now it will be checked first and return a normal error if it is incompatible to avoid rust-analyzer crashing.>
Fixed #22954

[ChayimFriedman2]

This is not the way. MIR eval is not at fault here. MIR lowering should fail on that code, and in fact any code that has a type checking error, but that is not implemented currently and perhaps will not suffice.

[YUZHEthefool]

根据您的反馈，我发现MIR lowering已经能区分builtin运算和成功解析的overloaded运算但是当“两者都不是”时依然错误地继续生成 CheckedBinaryOp，导致非法的MIR传递。
在进行测试时我发现部分合法 overloaded 运算没有记录method_resolution，因此更好的方式是inference结果中实际存在HAS_ERROR类型，所以我在整个body进入MIR lowering前统一返回HasErrors。
同时我删除了仅用于我个人测试的regression_22954，完善了fn overloaded_binop()测试的内容.

<Based on your feedback, I found that MIR lowering can already distinguish between builtin operations and successfully resolved overloaded operations. However, when an operation is neither, it still incorrectly proceeds to generate a CheckedBinaryOp, resulting in invalid MIR being passed on.

During testing, I also found that some valid overloaded operations do not have a corresponding method_resolution entry. Therefore, a better approach is to check whether the inference result actually contains a HAS_ERROR type and return HasErrors uniformly before lowering the body to MIR.

I also removed regression_22954, which was only used for my personal testing, and expanded the fn overloaded_binop() test.>