Preserve ArrayDimFetch expression tracking through loop generalization

[phpstan-bot]

Summary

• Fixes false positive "Offset ... on array ... might not exist" errors that occurred when an array dim fetch like $tmp[$id] was explicitly assigned inside a loop but its expression holder was removed during loop generalization of the parent variable
• Introduces a trackingOnly flag on ExpressionTypeHolder that preserves expression tracking through generalization while letting resolveType compute types fresh from the parent array via the ExprHandler
• Adds isExpressionTrackingOnly() guards in AssignHandler to prevent tracking-only holders from triggering setExistingOffsetValueType paths (which would cause type precision regressions)

Test plan

• New regression test testBug14598 with three scenarios: original reproducer, simple nested foreach, nested while loop — all produce no errors
• Existing pr-4390 test passes (no type precision regression on int<0, 9>)
• Existing bug-10438 test passes (no type precision regression on list<string>|string)
• make tests — 12063 tests, 79683 assertions pass
• make phpstan — no errors
• make cs-fix — no violations

Closes phpstan/phpstan#14598

[staabm]

reading the error message

Offset 'A'|'B'|'C' might not exist on non-empty-array{A?: list<'00'|'01'|'02'|'03'>, B?: list<'00'|'01'|'02'|'03'>, C?: list<'00'|'01'|'02'|'03'>}.

I think the type-system should be able to tell that a non-empty-array with known keys A|B|C will contain offset A|B|C

[phpstan-bot]

The branch is already up to date with origin — no additional commits or pushes needed.

Summary: After thorough investigation of the type-system approach, I've confirmed the trackingOnly mechanism is the minimal correct solution. The type-system cannot distinguish "this key was explicitly assigned in the current loop iteration" from "this key may or may not exist in a non-empty array" — that's a scope/flow-analysis concern, not a type concern. The trackingOnly flag bridges this gap by preserving expression tracking through generalization while preventing stale types from causing precision regressions.

[ondrejmirtes]

@staabm Hey, the message is correct.

[ondrejmirtes]

Offset 'A'|'B'|'C' might not exist on non-empty-array{A?: list<'00'|'01'|'02'|'03'>, B?: list<'00'|'01'|'02'|'03'>, C?: list<'00'|'01'|'02'|'03'>}.

You might have an array with key A (it's non empty and conforms to the type) and the offset 'A'|'B'|'C' might B so PHP will emit a notice about undefined offset.

[staabm]

You are right. Sealed vs. Unsealed territory