[Bug]: locator parser silently mis-parses \x / \u{…} escapes and some regex literals #43157

Version

main (1.65.0-next, 6936b23)

Steps to reproduce

Using unsafeLocatorOrSelectorAsSelector from packages/isomorphic/locatorParser.ts (used e.g. by the trace viewer / inspector locator box):

unsafeLocatorOrSelectorAsSelector('javascript', 'getByText("\\x41")');
// => internal:text="x41"i

unsafeLocatorOrSelectorAsSelector('javascript', 'getByText("\\u{1F600}")');
// => internal:text="\u0000 00}"i   (NUL followed by "00}")

// asLocator() itself produces this one, but it cannot be parsed back:
asLocator('javascript', 'internal:text=/[/]/');           // => getByText(/[/]/)
unsafeLocatorOrSelectorAsSelector('javascript', 'getByText(/[/]/)'); // throws "missing terminating ]"

Expected behavior

"\x41" → A, "\u{1F600}" → 😀, or a parse error. /[/]/ (a valid JS regex literal) round-trips.

Actual behavior

The new tokenizer (readString in the rewrite from #42895) only knows n r t b f and 4-digit \uXXXX; \x41 becomes x41, and \u{...} runs parseInt('{1F6', 16) → NaN → \0. The old parser rejected these inputs (returned ''), so this went from "unsupported" to "silently wrong selector". The regex-literal reader terminates on the first unescaped /, even inside a character class (this part is pre-existing).

Additional context

Regression from d6a10f6 (chore(locators): rewrite locator parser with per-language parsers).

Environment

Playwright main @ 6936b230a (1.65.0-next). Found by code review of recent commits; not OS/browser specific.