Fix "Token end is child end" crash when range formatting is inside a JSDoc comment

[johnfav03]

Fixes an issue uncovered in #4459 (comment) and #4532 (comment); getScanStartPosition() calls astnav.FindPrecedingToken(originalRange.Pos()) to get the starting position for the scanner. However, if Pos() is inside of a JSDoc, the scanner never sees the /** opener, and mis-scans the backtick as an undetermined template literal running to the end of the file, which produces a token whose end doesn't match the child's end and triggers the crash.

[Copilot]

Pull request overview

This PR fixes a formatter crash when range formatting starts from a position inside a JSDoc comment (notably at the start of a file), where the formatter’s scanner previously could begin scanning inside the comment and mis-tokenize backticks as an unterminated template literal.

Changes:

• Update range-format scan start calculation to use astnav.FindPrecedingTokenEx(..., excludeJSDoc=true) so the scanner won’t start inside a JSDoc comment.
• Add a new fourslash regression test that range-formats a selection starting inside a leading JSDoc containing a backtick, ensuring the operation does not crash.

Reviewed changes

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

File	Description
internal/fourslash/tests/rangeFormatInsideJSDocComment_test.go	Adds a regression test covering range formatting when the selection start is inside a leading JSDoc with a backtick.
internal/format/span.go	Adjusts scan start token discovery to exclude JSDoc so scanning doesn’t begin mid-comment.