feat(dsql): parse ALTER TABLE ASYNC

[agarwal-govind]

Summary

Aurora DSQL runs certain ALTER TABLE operations as asynchronous DDL jobs via the ALTER TABLE ASYNC form — most notably:

ALTER TABLE ASYNC t VALIDATE CONSTRAINT c

which returns a job_id and validates existing rows in the background (the same async DDL model as CREATE INDEX ASYNC, already supported on this branch). The parser currently rejects ALTER TABLE ASYNC ... because ASYNC is not recognized after TABLE.

This adds an async flag to the AlterTable AST node and parses the optional ASYNC keyword, following the existing CREATE INDEX ASYNC precedent.

Changes

• ast/ddl.rs: add AlterTable.async: bool + render ASYNC in Display (after ALTER TABLE , before IF EXISTS/ONLY).
• parser/mod.rs: parse_alter_table parses an optional ASYNC keyword. Non-async ALTER TABLE is unchanged.
• dialect/snowflake.rs: set async: false at the two AlterTable construction sites.
• tests/sqlparser_postgres.rs: round-trip tests for ALTER TABLE ASYNC ... VALIDATE CONSTRAINT, including ASYNC + IF EXISTS + ONLY.
• Cargo.toml: bump sqlparser-dsql 0.62.1 → 0.62.2 and note ALTER TABLE ASYNC in the description.

Testing

• Exact round-trip verified for ALTER TABLE ASYNC t VALIDATE CONSTRAINT c and ALTER TABLE ASYNC IF EXISTS ONLY public.t VALIDATE CONSTRAINT c.
• Full suites pass with no regressions: sqlparser_postgres (180) and sqlparser_common (471).

Why

Unblocks dsql-lint (awslabs/aurora-dsql-tools) from upgrading its VALIDATE CONSTRAINT rule from "guide to ASYNC" to full auto-fix + clean-pass of the valid ALTER TABLE ASYNC form, matching how CREATE INDEX ASYNC is handled. Part of the DSQL VALIDATE CONSTRAINT ASYNC ecosystem rollout (agent-plugins, mcp, aurora-dsql-orms, aurora-dsql-tools).

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.