Pass the dim fetch paired with the offset to shouldKeepList() and guard the tracked-link setExistingOffsetValueType() shortcut - #6466

Summary

A nested offset write like $a[X][Y] = … checked the wrong link of the dim-fetch chain at each dimension. produceArrayDimFetchAssignValueToWrite() walks array_reverse($offsetTypes), so at iteration $i the offset belongs to $dimFetchStack[$lastDimKey - $i], but the code looked up $dimFetchStack[$i]. With two or more dimensions the outermost offset was paired with the innermost link and vice versa, which produced both a false positive and unsound list<…> types:

• $groups[array_key_last($groups)][] = $value; lost the outer list (return.type false positive), because shouldKeepList() was asked about $groups[…][] while the outer write was being composed.
• $matrix[array_key_last($matrix)][$column] = $value; kept the row as a list, because the array_key_last() pattern was matched while $column was written into the row.
• isset($matrix[$row]); $matrix[$row][$column] = $value; kept the row as a list, because the tracked $matrix[$row] selected setExistingOffsetValueType() for the write of $column into the row.

Changes

src/Analyser/ExprHandler/AssignHandler.php:

• produceArrayDimFetchAssignValueToWrite() destructures the dim fetch from its own $offsetTypes entry (foreach (… as $i => [$offsetType, $writtenDimFetch])) and passes that to shouldKeepList(), so every list-keeping pattern is matched against the dimension it belongs to. The $arrayDimFetch !== null checks became unreachable and were dropped — $offsetTypes and $dimFetchStack always have the same length.
• The setExistingOffsetValueType() shortcut keeps consulting the tracked chain link, but when that link is not the one being written, the new trackedLinkImpliesOffset() requires the written offset to stay within the container's key type. A tracked neighbouring link does not prove the written offset exists; it is only the usual evidence when the key comes from the written structure itself (foreach ($rows as $k => $v) { $matrix[$i][$k] = …; }).
• isSameVariable() (used by the count(), array_key_first()/array_key_last() and array_search() patterns) now also compares property fetches, static property fetches and nested dim fetches, with isSameOffset() comparing literal and variable offsets. Only side-effect-free forms are compared.

Analogous cases probed and fixed by the same change (each covered by a test in tests/PHPStan/Analyser/nsrt/bug-15245.php):

• read-modify-write forms of the same nested target: +=, ++, ??=
• three-dimensional chains, and appends ($cube[…][0][] = …) at any depth
• $matrix[count($matrix) - 1][$column] = … (the count() pattern at the outer dimension)
• writes through a property root ($h->matrix[array_key_last($h->matrix)][$column]) and through a static property root
• list-keeping patterns whose container is a property, a static property or a nested dim fetch, which previously only worked for plain variables

Probed and found already correct, so no test was kept for them: isset($matrix[$row][$column]) followed by a write to the same cell (both links tracked, so both pairings agree), and unset()'s ExistingArrayDimFetch write path, which does not index $dimFetchStack by the loop variable.

Deliberately left alone: $list[array_key_first($list)] = … on a possibly empty list still yields non-empty-list<…> even though array_key_first([]) is null. tests/PHPStan/Analyser/nsrt/bug-14245.php::overwriteKeyFirstMaybeEmptyArray() documents that trade-off explicitly, so it is not treated as part of this bug.

Root cause

One index mismatch with two consequences, both in produceArrayDimFetchAssignValueToWrite():

1. shouldKeepList() received a dim fetch from the opposite end of the chain, so the $list[array_key_last($list)], $list[count($list) - n], $list[array_search(…)] and $list[$i + 1] patterns were matched at the wrong dimension — dropping list where it holds and adding it where it does not.
2. The same mismatched dim fetch decided between setExistingOffsetValueType() (which keeps list and adds non-empty) and setOffsetValueType().

Only the middle link of an odd-length chain happened to line up, which is why one-dimensional writes were always fine. The fix pairs each offset with its own link; for the write-semantics decision the historical lookup is kept but is no longer accepted when the written offset can leave the container's key range, which is exactly the case the issue reports.

Test

• tests/PHPStan/Analyser/nsrt/bug-15245.php — the three functions from the issue verbatim, asserting non-empty-list<non-empty-list<int>>, non-empty-list<array<int, int>> and non-empty-list<non-empty-array<int, int>>, plus the analogous cases listed above. 14 of its assertions fail without the fix.
• tests/PHPStan/Rules/Functions/ReturnTypeRuleTest::testBug15245() with tests/PHPStan/Rules/Functions/data/bug-15245.php — locks in that the return.type false positive on appendToLastGroup() is gone and that the two false negatives on setInLastRow() and setInExistingRow() are now reported.

Fixes phpstan/phpstan#15245