Fix startup crash when redefining global Array with @noLib

[hayatexe]

Fixes #57009

Description
When --noLib is specified and a user statically re-defines Array through a generic type alias (e.g. type Array<T> = T[]), attempting to build the program causes the compiler to hit a crash early in the startup phase.

The issue occurred because the globalArrayType is resolved dynamically via getGlobalType. In --noLib scenarios, the alias for Array matches the global type, invoking type resolution to load the Array's target type before globalArrayType has finished initializing. When evaluating T[], getArrayOrTupleTargetType is called and tries to return globalArrayType (which is still undefined). This caused target inside getTypeFromArrayOrTupleTypeNode to be undefined, which subsequently crashed on createDeferredTypeReference(target, ...) because it accessed target.symbol.

This PR fixes the crash by explicitly letting getArrayOrTupleTargetType fallback to emptyGenericType instead of returning undefined. This resolves the dependency cycle cleanly and causes the checker to produce expected diagnostic errors (Global type 'Array' must have 1 type parameter(s)) instead of crashing the process.

A regression test is included.

[typescript-bot]

With 6.0 out as the final release vehicle for this codebase, we're closing all PRs that don't fit the merge criteria for post-6.0 patches. If you think this was a mistake and this PR fits the post-6.0 patch criteria, please post to the 6.0 iteration issue with details (specifically, which PR and which patch criteria it satisfies).

Next steps for PRs:

• For crash bugfixes or language service improvements, PRs are currently accepted at the typescript-go repo
• Changes to type system behavior should wait until after 7.0, at which point mainline TypeScript development will resume in this repository with the Go codebase
• Library file updates (lib.d.ts etc) continue to live in this repo or the DOM Generator repo as appropriate