Why is this needed?

This is a sub-issue of #7902.

We need to integrate ty into our CI pipeline as the first step toward adopting it as our Python type checker. To enable incremental adoption, ty should be configured to exclude modules that currently have diagnostics, allowing CI to pass while we address issues in subsequent PRs.

Which area does this relate to?

• Static typing
• Automation

Solution

1. Add ty as a dev dependency
2. Configure ty in pyproject.toml excluding modules with existing diagnostics:
   • logging/ (1 diagnostic)
   • utilities/validation/ (1 diagnostic)
   • shared/ (2 diagnostics)
   • metrics/ (2 diagnostics)
   • middleware_factory/ (2 diagnostics)
   • utilities/streaming/ (2 diagnostics)
   • utilities/parameters/ (4 diagnostics)
   • utilities/parser/ (5 diagnostics)
   • utilities/data_masking/ (6 diagnostics)
   • tracing/ (13 diagnostics)
   • utilities/data_classes/ (14 diagnostics)
   • utilities/batch/ (18 diagnostics)
   • utilities/idempotency/ (19 diagnostics)
   • event_handler/ (85 diagnostics)
3. Add GitHub Actions workflow job for ty
4. Ensure CI passes with the baseline configuration

Acknowledgment

• This request meets Powertools for AWS Lambda (Python) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Java, TypeScript, and .NET