Fix go-to-type-definition on tuples

[DanielRosenwasser]

Tuples are internally just type references of a given size, but with no associated symbol, so we need to guard on them.

Fixes #2847.

[Copilot]

Pull request overview

Fixes a panic in the Go port’s LSP textDocument/typeDefinition handler when invoked on tuple types, which are represented as type references without an associated symbol.

Changes:

• Add a nil guard for t.symbol in Checker.GetFirstTypeArgumentFromKnownType to avoid nil dereference on tuple type references.
• Add a new fourslash regression test for go-to-type-definition on tuple types (including via a tuple type alias).
• Add the corresponding reference baseline for the new fourslash test.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
internal/checker/services.go	Prevents panic by guarding t.symbol before reading t.symbol.Name in known-generic handling.
internal/fourslash/tests/goToTypeOnTuples_test.go	Adds a regression test that exercises go-to-type-definition in tuple-related scenarios.
testdata/baselines/reference/fourslash/goToType/goToTypeOnTuples1.baseline.jsonc	Adds expected baseline output for the new go-to-type-definition fourslash test.

[Copilot]

The first marker is placed on a commented-out line (// export let x...). If the caret is inside a line comment, GetTouchingPropertyName can end up returning the SourceFile/nearest enclosing node, so the type-definition request may early-return and never exercise the tuple-type codepath. Consider removing the leading // so marker 1 actually tests go-to-type-definition on a tuple annotation, matching the reported repro and ensuring this case is covered.