Fix phpstan/phpstan#14170: lost list in iterable type after iteration

[phpstan-bot]

Summary

When iterating over an iterable<string, list<string>> and modifying elements via nested array dim fetch assignment ($convert[$outerKey][$key] = ...), the list type was lost and the variable's type degraded to array<string, mixed>|iterable<string, list<string>> instead of remaining iterable<string, list<string>>.

Changes

• Override getOffsetValueType() on IterableType (src/Type/IterableType.php) to return the actual item type instead of mixed (from MaybeOffsetAccessibleTypeTrait)
• Skip the generalOffsetAccessibleType intersection for iterable types in produceArrayDimFetchAssignValueToWrite (src/Analyser/ExprHandler/AssignHandler.php) to prevent decomposing iterable into array|ArrayAccess union
• Update existing test expectation in tests/PHPStan/Analyser/nsrt/iterable.php to reflect the now-correct offset value type for typed iterables

Root cause

Two issues combined to cause the bug:

1. IterableType::getOffsetValueType() inherited from MaybeOffsetAccessibleTypeTrait returned mixed instead of the item type. When processing nested array dim fetch assignments like $convert[$outerKey][$key], the intermediate value type at $convert[$outerKey] became mixed, losing the list<string> information.

2. In produceArrayDimFetchAssignValueToWrite, the iterable type was intersected with generalOffsetAccessibleType (array|ArrayAccess|null), which decomposed the iterable compound type into separate array and ArrayAccess branches, permanently losing the iterable identity.

Test

Added regression test tests/PHPStan/Analyser/nsrt/bug-14170.php with two test cases:

• example3a: Iterating with references (already worked correctly)
• example3b: Iterating with explicit key access and array dim assignment (was failing, now passes)

Fixes phpstan/phpstan#14170