[FEATURE] Unify async query PPL processing via unified query API

[dai-chen]

Is your feature request related to a problem?

The async-query module currently maintains its own PPL parsing and validation stack that is separate from the Unified Query API. Long-term, as the PPL specification and reference implementation, the Unified Query API should be the single entrypoint and reusable library for PPL consumers and adopters.

What solution would you like?

Integrate the async-query module with the Unified Query API to leverage its PPL parsing capabilities:

0. Prerequisite: Add a UnifiedQueryParser component to the Unified Query API that exposes PPL parsing as a standalone capability, enabling syntax validation without requiring full planning context.
1. Unified PPL Parsing: Replace PPLQueryValidator's use of OpenSearchPPLParser with UnifiedQueryParser, eliminating the duplicate ANTLR parser in async-query-core.
2. AST-Based Validation: Migrate PPLQueryValidationVisitor from CST-based (parse tree) validation to AST-based validation using the unified query AST, enabling richer semantic checks beyond grammar element deny lists.
3. Datasource Capability Model: Refactor GrammarElementValidatorProvider and deny-list validators (S3GlueSQLGrammarElementValidator, SecurityLakeSQLGrammarElementValidator etc) into a datasource capability model that integrates with the unified query API's semantic analysis.

What alternatives have you considered?

• Keep separate implementations: Maintain independent PPL parsing in async-query. This was rejected because it increases maintenance burden and risks behavioral divergence between direct and async query execution.

Do you have any additional context?

Current Architecture:

PPLQueryValidator:          PPL String → OpenSearchPPLParser (CST) → PPLQueryValidationVisitor 
                                       → GrammarElementValidatorProvider → Deny List Check

Target Architecture:

PPLQueryValidator:          PPL String → UnifiedQueryParser → AST → All validations