Do not record conditional expressions for MethodCall/StaticCall when assigned expression contains nullsafe chain

[phpstan-bot]

Summary

PR #5447 added MethodCall and StaticCall to the allowed expression types in processSureTypesForConditionalExpressionsAfterAssign, enabling type narrowing for method call results assigned to variables (e.g. $hasA = $b->getA() !== null; if ($hasA) { $b->getA(); }). However, this also caused false positives when the assigned expression was a nullsafe chain: the TypeSpecifier's chain decomposition produces sure types for intermediate sub-expressions (like $order->getOrderCustomer() from $order->getOrderCustomer()?->getCustomer()?->getAccountType()), and these were incorrectly persisted as conditional expressions.

Changes

• Added exprContainsNullsafe() helper method in src/Analyser/ExprHandler/AssignHandler.php that recursively checks whether an expression contains any NullsafeMethodCall or NullsafePropertyFetch
• Added $assignedExprContainsNullsafe parameter to processSureTypesForConditionalExpressionsAfterAssign() and processSureNotTypesForConditionalExpressionsAfterAssign()
• When the flag is true, MethodCall and StaticCall expressions in the sure types are skipped (not recorded as conditional expressions)
• All call sites updated to pass the flag

Analogous cases probed

• NullsafePropertyFetch with MethodCall var: Same issue — a chain like $a->getB()?->prop?->subProp would narrow $a->getB() through conditional expressions. Fixed by the same mechanism (the assigned expression contains NullsafePropertyFetch). Added test.
• StaticCall in nullsafe chain: Already covered in the reproduction test ($order::getStaticOrderCustomer()?->...).
• Direct method call narrowing (bug #9455): Verified still working — $hasA = $b->getA() !== null does NOT contain any nullsafe operator, so the conditional expression is still recorded correctly.
• PropertyFetch: Not affected — PropertyFetch was in the allowed list before PR Fix phpstan/phpstan#9455: Bug: False report Cannot call method getId() on A|null #5447 and property accesses are stable within a scope.
• FuncCall: Not affected — FuncCall was in the allowed list before PR Fix phpstan/phpstan#9455: Bug: False report Cannot call method getId() on A|null #5447 and is not skipped by the new filter.

Root cause

The TypeSpecifier decomposes NullsafeMethodCall chains into BooleanAnd(var !== null, MethodCall(var, name, args)) conditions. This produces sure types for intermediate expressions (e.g., $order->getOrderCustomer() is not null when the chain result is non-null). PR #5447 allowed these MethodCall/StaticCall sure types to be recorded as conditional expressions tied to the assigned variable. After a subsequent check narrowed the assigned variable, the conditional expressions fired and incorrectly narrowed the intermediate method call for all future uses — triggering the nullsafe.neverNull rule.

Test

• tests/PHPStan/Rules/Methods/data/bug-14493.php — reproduces the reported false positive with both instance method calls and static method calls in nullsafe chains
• tests/PHPStan/Rules/Properties/data/bug-14493.php — reproduces the analogous false positive with NullsafePropertyFetch chains where the var is a method call
• Both tests expect zero errors (false positives eliminated)

Fixes phpstan/phpstan#14493