Validate aws-cli CloudFormation commands

[satyakigh]

Description of changes:

Adds offline validation of AWS CLI (botocore) API calls by modeling them as CloudFormation resource state, exposed as validate_aws_cli_command in validation-engine and as validateAwsCliCommand / validate_aws_cli_command / ValidateAwsCliCommand in the JVM, Node.js (WASM), Python, and Go bindings.

What it does

Given a botocore service name, operation name, and the request parameters the CLI is about to send, the engine returns an AwsCliCommandValidation with an operation kind, a VALIDATED or SKIPPED status, the template source, the CloudFormation resource type(s) involved, a human-readable reason, the exact template bytes that were validated, and — when validated — a STANDARD-level ValidationReport.

1. CloudFormation operations with a TemplateBody (CreateStack, UpdateStack, CreateChangeSet, ValidateTemplate, …) validate the caller's template bytes unchanged. TemplateURL is skipped (offline).
2. Cloud Control CreateResource wraps the exact DesiredState as a single resource of TypeName.
3. Every other operation is looked up in a generated adapter catalog that maps one (service, operation) to one CloudFormation resource type with explicit parameter → property pairs. A one-resource template is synthesized and validated through the normal pipeline; diagnostics are scoped to the properties the call actually set, and template-authoring advice (use a parameter / Ref / dynamic reference) is dropped because there is no template author.
4. Operations without an adapter are classified by verb and HTTP method (READ_ONLY, DATA_PLANE_MUTATION, UNMAPPED_MUTATION) and skipped. Delete adapters classify but never synthesize.

Deterministic, no false positives

Modeling is never guessed. A command is validated only when every supplied parameter is accounted for, and any doubt results in SKIPPED with a reason naming the parameter:

• Closed catalog. Only exact (service, operation) keys resolve; there is no name-based inference of resource types.
• All-or-nothing mapping. Every supplied parameter must map to a writable property with a representable value or be a declared request-control field (idempotency tokens, DryRun, the primary identifier on updates). Only scalars, arrays of scalars, and string-map Tags → Key/Value arrays are mapped; nested structures are never rewritten.
• API-valid values are never reported as CloudFormation violations. Each mapping records the value domain the service accepts but the CloudFormation schema rejects (unrepresentable: enum members, numeric bounds, string lengths, list sizes, tag key/value lengths, and — when the botocore and CloudFormation regexes differ — the pattern pair, settled per value: a value the API pattern accepts and the CloudFormation pattern rejects skips synthesis). Same-named inputs whose meaning differs from the property (an API resource ID where CloudFormation wants the ARN) are excluded by a reviewed denylist.
• Update calls synthesize only the explicitly updated properties, so missing-required findings cannot fire against partial state.