[kvlonge]

Why

Three demo queries came out wrong. == converted to = although Snowflake rejects it, and TOP n and FETCH FIRST n ROWS ONLY were refused although LIMIT expresses them exactly.

Changes

• == is now a check finding, SQ0206 double_equals, worded as Snowflake reports it: "Unknown function ==", with help to compare with =. Snowflake parses == and rejects it when compiling (errno 2139, recorded in corpora/everyday/snowflake-receipts.json), so parsing still accepts it, and the finding refuses the statement before conversion. The diagnostics reference is regenerated.
• TOP n and FETCH { FIRST | NEXT } n { ROW | ROWS } [ ONLY ] convert to LIMIT n, after ORDER BY and DISTINCT. PERCENT, WITH TIES, a count that is not an integer literal, and more than one of LIMIT, TOP and FETCH stay refused.

Converted SQL in the playground corpora (basics, everyday, everyday-models, examples), before and after. Only these 3 of 2,962 statements change:

Query	Before	After
SELECT TOP 5 * FROM orders	refused SQ0002	SELECT ... FROM "ORDERS" AS "ORDERS" LIMIT 5
SELECT order_id FROM orders FETCH FIRST 10 ROWS ONLY	refused SQ0002	SELECT "ORDERS"."ORDER_ID" AS "ORDER_ID" FROM "ORDERS" AS "ORDERS" LIMIT 10
SELECT order_id FROM orders WHERE status == 'shipped'	converted to = 'shipped'	check SQ0206 Unknown function ==

Verification

• Replay: the 8 recorded top-n and limit.fetch cases go from refused to matching, and their 8 obligations are met. 0 regressions. The translation results and SQL size baselines are re-recorded.
• Corpus verdicts are unchanged, and no Snowflake syntax receipt has == as an operator.
• New tests cover == rejections and non-rejections (strings, comments, >=, !=), check exiting 1 with SQ0206, TOP/FETCH rows run on DuckDB, and the PERCENT, WITH TIES and TOP-with-LIMIT refusals.
• make check-ci passes.