Fix crash inferring constrained variadic tuples with optional elements

[Andarist]

followup to #2928
ports microsoft/TypeScript#63014

[Copilot]

Pull request overview

This PR ports microsoft/TypeScript#63014 as a follow-up to #2928. It adds arity guards in inferFromObjectTypes so that when inferring a [...T, ...rest] or [...rest, ...T] shaped target (where T is constrained by a fixed-size tuple) against a source tuple, inference is only performed if the source actually has enough fixed elements to support the implied arity. This prevents incorrect/spurious inferences (and crashes) when the source's fixed-element count is smaller than the constraint's fixed length—particularly common with optional elements in the constraint.

Changes:

• Guard the [...T, ...rest] middle case with startLength+impliedArity <= source.fixedLength.
• Guard the [...rest, ...T] middle case with endLength+impliedArity <= getEndElementCount(source, ElementFlagsFixed) and move the trailing-slice inference inside the guard.
• Add a new compiler test (inferTypesWithFixedTupleExtendsAtVariadicPosition2.ts) plus its .types, .symbols, and .errors.txt baselines.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
internal/checker/inference.go	Adds arity guards in the two variadic+constrained-tuple inference branches
testdata/tests/cases/compiler/inferTypesWithFixedTupleExtendsAtVariadicPosition2.ts	New test covering many infer B extends [..] variadic tuple shapes incl. optional elements
testdata/baselines/reference/compiler/inferTypesWithFixedTupleExtendsAtVariadicPosition2.types	Type baseline for the new test
testdata/baselines/reference/compiler/inferTypesWithFixedTupleExtendsAtVariadicPosition2.symbols	Symbol baseline for the new test
testdata/baselines/reference/compiler/inferTypesWithFixedTupleExtendsAtVariadicPosition2.errors.txt	Errors baseline for the new test

[Andarist]

fixedLength still includes optional elements. In those cases, the checker could assume it needed more fixed source elements even when fewer were guaranteed, and that led to invalid slice math and crashing

[jakebailey]

We have a couple of PRs touching this same code, e.g. #3917, #2928; I feel a little unclear what combo is correct in all of these