Do not assign ErrorType back to array when assign-op result is an error

[phpstan-bot]

Summary

When multiple assign-ops (e.g., +=) are performed on different keys of the same array, only the first operation was flagged as an error. Subsequent operations on sibling keys were silently missed because the first assign-op's ErrorType result corrupted the array's value type.

Changes

• Modified src/Analyser/ExprHandler/AssignHandler.php to detect when an assign-op produces ErrorType and preserve the original element type instead of assigning ErrorType back:

  • ArrayDimFetch branch (line ~421): Recovers original type by traversing the offset chain from the base variable type
  • ExistingArrayDimFetch branch (line ~779): Same recovery pattern for the existing-offset path
  • Variable branch (line ~242): Preserves the variable's original type when assign-op result is ErrorType

• Added rule test tests/PHPStan/Rules/Operators/data/bug-10349.php covering:

  • Multiple += in a foreach loop (issue 1-A from the report)
  • Mixed narrowed/erroneous += in a foreach loop (issue 1-B)
  • Multiple += outside a loop
  • Simple (non-nested) array with multiple +=
  • Other assign-ops: -=, *=, /=, %=, .=, <<=

• Added NSRT test tests/PHPStan/Analyser/nsrt/bug-10349.php verifying the array element type is preserved after an error-producing assign-op

Root cause

ErrorType extends MixedType. When an assign-op like (bool|float|int|string) += int produces ErrorType as its result type, this ErrorType was assigned back to the array element via setOffsetValueType/setExistingOffsetValueType. Inside these methods, the new value type is unioned with the existing value type via TypeCombinator::union. Since ErrorType (as a MixedType) absorbs all other types in a union, the array's entire value type became MixedType. All subsequent accesses to any key of that array then returned MixedType instead of the original declared type, suppressing further error reports.

The fix preserves the original element type when the assign-op result is ErrorType, since at runtime a failed operation (TypeError) would leave the variable unchanged.

Analogous cases probed

• Property assign-ops ($obj->prop += $x): Not vulnerable — properties don't use nested offset type unwinding, so ErrorType doesn't propagate to sibling properties.
• InvalidComparisonOperationRule / InvalidUnaryOperationRule: Not affected — these rules only report errors without assigning types back.
• OffsetAccessAssignOpRule: Not affected — only validates and reports, doesn't assign types.

Test

• Rule test verifies all assign-op variants (+=, -=, *=, /=, %=, .=, <<=) report errors on every array key, not just the first
• NSRT test verifies sibling array element types are preserved after an error-producing assign-op

Fixes phpstan/phpstan#10349