Preprocessor reports false "Invalid number literal: exponent has no digits" for hex literals such as `0x9E`

Description

The preprocessor's lexer doesn't recognise hexadecimal (or Luau binary) literals. It splits them into two tokens, and if the second half looks like an incomplete exponent it reports a false error. This makes valid scripts fail to preprocess.

Steps to reproduce

1. Open a Luau (or LSL) script with the preprocessor enabled.
2. Add a line containing a hex literal whose digits include a decimal digit immediately followed by E/e, with no digit after it:

   base = writeBytecode(state, { 0x9E, 16, 0 })
   

3. Save the file.

Expected behaviour

The line preprocesses without error. 0x9E is valid and equals 158.

Actual behaviour

Preprocessing fails and the Problems panel shows:

Invalid number literal: exponent has no digits   (source: "luau Preprocessor")

The script isn't synced, and the only other feedback is a generic "Preprocessing failed" toast.

Cause

Lexer.readNumber in src/shared/lexer.ts had no hex or binary handling. For 0x9E:

1. It read the integer part 0.
2. It then consumed the next identifier-start character x as a numeric "suffix", producing the token 0x.
3. Lexing resumed at 9E, which it read as the digit 9 followed by an exponent marker E with no digits after it, and reported the error.

Scope

Any hex literal was mis-tokenised. It only produced an error when a decimal digit was directly followed by E/e and then a non-digit, for example 0x9E, 0x1E or 0x0E. Other forms were split silently and harmlessly, since tokens are re-emitted verbatim:

Fix

readNumber now recognises 0x… and 0b… up front and returns the whole literal as a single NUMBER_LITERAL token, without going through the exponent or suffix logic. It only does so when a valid digit follows the prefix, so a bare 0x and every other literal behave as before. Genuine bad exponents such as 123e and 1.5e+ are still reported.

Regression tests were added to src/test/suite/lexer-diagnostics.test.ts, covering the reported case, mixed-case hex, Luau binary, 0x1E+2, and the bare-prefix case.

Start in src/shared/lexer.ts at Lexer.readNumber and review the regression coverage in src/test/suite/lexer-diagnostics.test.ts. Reproduce the reported 0x9E case along with the listed hexadecimal, Luau binary, bare-prefix, and malformed-exponent cases. Done means valid literals preprocess without diagnostics while genuine bad exponents still report errors.