feat: parse BigQuery JSON string literals as implicit casts

[hayssams]

Problem

BigQuery-style JSON string literals fail to parse on the manticore branch:

SELECT BOOL(JSON 'true') AS vacancy
SELECT SAFE.FLOAT64(JSON '9.8') AS result
SELECT JSON_VALUE(JSON '{"name": "Jakob"}', '$.name') AS name

all throw ParseException: Encountered: <S_CHAR_LITERAL> at the literal after JSON. These parsed fine before the Pratt-parser rework (e.g. in the 5.4-SNAPSHOT line from late 2025).

Cause

isImplicitCastAhead() only treats DT_ZONE and DATA_TYPE tokens as implicit-cast prefixes. JSON lexes as K_JSON (it is needed as a keyword elsewhere: FORMAT JSON, FOR JSON AUTO, ...), so JSON 'literal' never reaches ImplicitCast(), even though DataType() already accepts K_JSON as a data type. Inside function arguments the parser then consumes JSON as a column and fails on the following string literal.

Fix

Accept K_JSON in isImplicitCastAhead() when it is directly followed by a string literal, which is unambiguous with all keyword uses of JSON:

// BigQuery JSON 'literal' - JSON lexes as K_JSON, but DataType() accepts it
if (k1 == K_JSON) return getToken(2).kind == S_CHAR_LITERAL;

Adds a regression test to CastExpressionTest covering the standalone literal and the function-argument case.

Validated against the JSQLTranspiler test suite (1042 tests), where this fix resolves 24 BigQuery JSON parse failures without affecting any other test.

🤖 Generated with Claude Code

[hayssams]

@manticore-projects when you have a moment, could you take a look at this one? It restores BigQuery JSON 'literal' parsing on the manticore branch (2-line change in isImplicitCastAhead() plus a regression test). It unblocks the JSQLTranspiler test suite, which is fully green against a local build of this branch with the fix (1050 tests). Thanks!

[manticore-projects]

Thank you very much!