fix(scripts): count comments after regex literals in the comment ratchet

[miguel-heygen]

What broke

The comment scanner behind the comment checks blanked string literals but not regex literals. A regex
such as /["'`]([^"'`]+)["'`]/g left an unpaired backtick behind, which the scanner read as the start
of a multi-line template literal, so every comment until the next backtick went uncounted. It also
read a // or /* inside a regex body (/^\/\//, /\/\*[\s\S]*?\*\//) as a comment.

Effect on the ratchet: packages/studio/src/utils/gsapSoftReload.ts measured 95 comment lines while
it really has 172, and merely moving that regex made a PR look like it added dozens of comment lines.

Fix

scanCLike now blanks strings and regex literals in one left-to-right pass. A / starts a regex
unless the previous significant character is an identifier, number, ), ], < (a JSX closing tag),
or the line so far ends in ++ or --, and only when the literal closes on the same line. A regex never
closes on a comment opener, so a / whose would-be closer starts // or /* is treated as division;
that covers a line that opens with division continued from the line above, which a per-line scan cannot
see, while a real regex at the start of a line is still blanked. Python and the restates-code rule keep stripStrings.

Across the 1774 package source files, 52 change count. Every change is either comments that were
hidden after a regex (gsapSoftReload 95 -> 172, inlineSubCompositions 19 -> 158, probeStage
52 -> 106, useClipboard 20 -> 51, gsap rule 311 -> 340) or a regex body that was miscounted as a
comment (one line each). gsapSoftReload now matches a count taken with the TypeScript scanner exactly.

The ratchet compares each file against its own merge-base copy with the same script, so there is no
stored baseline to update and the higher counts cannot fail an unrelated PR.

Test

comment-ratchet.test.mjs adds a source with a regex holding ', " and a backtick, followed by
line, trailing and block comments and two divisions. It measures 0 comment lines without the fix and
4 with it. Three more tests pin JSX closing tags, ++/-- before division, and a line that opens with
division; each goes from 0 to 1, and removing any one of the three rules fails its own test.

Merged below the usual size floor: opened minutes after the one-PR-per-lane rule landed, before the lane had it, and it fixes the comment check every PR runs, so it should not wait inside a larger PR.