fix: add test for failing regression and fix program.comments not sorted by range

[johanrd]

Follow-up to #196.

Observed

With #196 applied, program.comments comes out unsorted whenever a JS /* */ comment sits between two templates:

const X = <template>
  {{! glimmer comment at 22 }}
</template>;
/* js comment at 56 */
const Y = 1;
// ast.comments: [[65,87] js, [23,51] glimmer]  ← unsorted

ESLint's SourceCode builds tokensAndComments = sortedMerge(ast.tokens, ast.comments) and the token-store's createIndexMap(tokens, comments) — both assume each input array is sorted by range[0] (espree, @typescript-eslint/parser, @babel/eslint-parser all honor that invariant). With unsorted comments, the index map points at the wrong token indices for positions whose nearest comment was iterated out of order, which surfaces as wrong answers from sourceCode.getTokenBefore(commentNode) / getTokenAfter(commentNode):

	getTokenBefore(glimmer@[23,51])	getTokenAfter(glimmer@[23,51])
#196 as-is	; @ [63,64] (wrong — after the comment)	const @ [88,93] (skips </template>)
with this PR	<template> @ [10,20]	</template> @ [52,63]

Commits

1. test: — tests/program-comments-sort-order.test.js, two tests that pin the invariant:
   • Structural: ast.comments.map(c => c.range[0]) equals its sorted copy.
   • End-to-end via Linter: for the {{! }} comment, getTokenBefore / getTokenAfter return tokens that bracket the comment (before-end ≤ comment-start, after-start ≥ comment-end).
2. fix: — sort the concatenated array after appending Glimmer comments in gjs-gts-parser.js (programNode.comments = […TS, …glimmer].sort((a, b) => a.range[0] - b.range[0])).

Verification

• Both tests fail on the test: commit alone, pass after fix:.
• npm run lint and prettier --check clean.

Review comment companion

I also ran eslint-plugin-ember#2733's five-test directive suite against #196 + this fix — all 5 pass.