Type checker: reject uint32-range array indices (drifts from runtime)

[nickna]

Impact

Significant portion of the 880 TypeCheckError files in built-ins/Array (baseline: SharpTS.Test262/baselines/interpreted.txt).

Problem

Post-#73, the runtime handles the full ECMA-262 uint32 index range:

var a = [0, 1, 2];
a[4294967295] = "spec-legal sparse index";  // runtime: OK, length stays 3
assert.sameValue(a.length, 3);

But the type checker still rejects a[4294967295] as an out-of-range index, producing TypeCheckError before the runtime ever sees it. One half of the engine caught up on the sparse-array migration; the other didn't.

Representative failing test: test/built-ins/Array/15.4.5.1-5-2.js.

Suggested fix

Relax the type checker's array index-range guard to permit any uint32 value (matches SharpTSArray.LongLength / Set(long, ...) runtime API). Mechanical change — the runtime already does the right thing.

Suggested starting point

• TypeSystem/ — grep for int.MaxValue / uint32 / index-range bounds in array member access.
• Check TypeChecker.Properties.Helpers.cs / array index resolution paths.

Acceptance

Re-running Test262 subset moves the affected TypeCheckError files off that bucket (most to Pass, some to RuntimeError where a distinct bug is exposed — which is fine, that's the next layer of visibility).

Related

Depends on #73 (sparse arrays) — complete.

[nickna]

Verified complete via PR #98 (commit 937c295).

• Fix landed: IsArrayIndexInRange in TypeSystem/TypeChecker.Properties.Index.cs:606 gates element-type checks in CheckSetIndex / CheckSetIndexOnType so out-of-range numeric literals (e.g. a[4294967295], a[-1]) no longer fire TypeCheckError.
• Coverage: tests added in SharpTS.Tests/TypeCheckerTests/TypeErrorTests.cs.
• Acceptance: baselines/interpreted.txt shows built-ins/Array/15.4.5.1-5-2.js moved TypeCheckError → RuntimeError (the next-layer runtime concern, as called out in the issue).

Note: baselines/compiled.txt still shows TypeCheckError for the same test, but this is a stale baseline from a botched merge conflict resolution in 6c012d2, not a code regression — both modes share the same TypeChecker.Check(). Tracking the baseline refresh separately.