Is your feature request related to a problem?

Aurora MySQL extends MySQL with LOAD DATA FROM S3 — the syntax AWS documents as the canonical way to bulk-load data from S3 (https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.LoadFromS3.html). Aurora instances register in Bytebase as the MYSQL engine, but the MySQL parser does not recognize this syntax, so plan checks report a false syntax error (verified on current main, first hit on 3.17.0):

Syntax error #201
Syntax error at line 1:11: unexpected token
related text: LOAD DATA FROM S3 's3://mybucket/data.txt' INTO TABLE t1 ...

Consequences:

• With enforce_sql_review enabled, the plan cannot be submitted for review (FailedPrecondition: Plan checks did not pass). Without it, the automatic rollout never triggers, and the only way through is "Bypass and deploy" — skipping review approval entirely.
• Execution itself works: the task runner sends the statement as-is and Aurora runs it. Only the parser stands in the way, so a legitimate, auditable statement (Aurora logs every load in aurora_s3_load_history) can only pass the governed path by stacking governance exceptions.

There is no workaround on the MySQL side: LOAD DATA is banned from stored procedures (ERROR 1314) and from PREPARE, so it cannot be wrapped in standard syntax — unlike Aurora PostgreSQL, whose aws_s3.table_import_from_s3() is a plain function call and parses fine today.

Reproduction (no Aurora needed): create a plan targeting any MySQL-engine database with

LOAD DATA FROM S3 's3://mybucket/data.txt' INTO TABLE t1
FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n';

and both plan checks (STATEMENT_ADVISE, STATEMENT_SUMMARY_REPORT) fail with Syntax error #201.

Describe the solution you'd like

Have the MySQL parser accept the Aurora MySQL S3 statements so plans containing them pass the syntax check and get normal SQL review coverage:

• LOAD DATA FROM S3 [FILE | PREFIX | MANIFEST] 'uri' ... (and LOAD XML FROM S3 ...)
• SELECT ... INTO OUTFILE S3 'uri' ...

These two are the only Aurora-specific statements relevant to change workflows; everything else Aurora exposes uses standard syntax.

Additional context

This looks consistent with the parser stack's direction: bytebase/omni's MySQL lexer already defines an S3 keyword (currently unused), and omni already extends the MySQL grammar per dialect (omni/mariadb adds INSERT ... RETURNING and CREATE SEQUENCE).

Happy to contribute the parser change if this direction sounds acceptable.