feat(detector-aws): detect Lambda availability zone metadata

[garysassano]

Which problem is this PR solving?

• @opentelemetry/resource-detector-aws currently detects standard AWS Lambda cloud and faas attributes, but it does not populate cloud.availability_zone.
• AWS Lambda now exposes execution-environment AZ metadata through a local metadata endpoint, which makes this attribute available without requiring an external service call.
• The OpenTelemetry semantic conventions define cloud.availability_zone, so the Lambda detector can now populate it consistently with the other AWS resource detectors.

Short description of the changes

• Add Lambda metadata endpoint support to the AWS Lambda detector and map AvailabilityZoneID to cloud.availability_zone.
• Keep the existing environment-variable-based Lambda attributes unchanged and best-effort.
• Suppress internal tracing for the new localhost HTTP request, matching the package’s existing detector behavior.
• Add unit coverage for successful metadata lookup and failure fallback behavior.
• Extend the internal tracing integration test to exercise the Lambda metadata path.
• Document the new attribute in the package README.

Reasoning

This change stays close to the new Lambda platform feature and the existing detector design. The detector already reads Lambda runtime metadata from environment variables when it is running inside Lambda, so using the Lambda-provided localhost metadata endpoint for the AZ value is the smallest extension of that model.

I chose a direct HTTP call instead of using Powertools. That keeps the detector self-contained and avoids introducing a new runtime dependency on @aws-lambda-powertools/commons, or assuming that Powertools is already present through a Lambda layer. For a generic OpenTelemetry detector library, the direct endpoint call is the safer default.

The implementation stores the Lambda-provided AZ identifier as-is. Lambda returns an AZ ID such as use1-az1, not an AZ name such as us-east-1a. That value is still useful because AZ IDs are consistent across AWS accounts, while AZ names are not.

Possible optimizations

• Powertools path: if this package ever accepts an explicit Powertools dependency or an optional integration layer, the detector could use the Powertools metadata utility instead of making its own HTTP request. That would delegate response caching and SnapStart-aware refresh behavior to AWS-maintained code.
• Optional translation to AZ name: if a consumer explicitly wants an AZ name instead of the Lambda AZ ID, a separate opt-in path could translate the ID through DescribeAvailabilityZones. I did not add that here because it would require additional IAM permissions, another API dependency, and would move the detector away from the value Lambda directly exposes.
• Shared metadata helper: if more Lambda-specific metadata fields are added later, the package could factor the HTTP request code into a reusable helper. Right now that would be premature because only one new field uses the endpoint.

Testing

• Added unit tests for successful AZ metadata detection and graceful fallback when the metadata endpoint returns an error.
• Updated the internal tracing integration fixture to use AWS_Lambda_nodejs24.x.
• I could not run the package test suite in this checkout because the repository dependencies are not installed locally, so npm test -w @opentelemetry/resource-detector-aws currently fails before executing tests.

References

1. OpenTelemetry semantic conventions, cloud.availability_zone: https://opentelemetry.io/docs/specs/semconv/registry/attributes/cloud/#cloud-availability-zone
2. AWS Lambda metadata endpoint developer guide: https://docs.aws.amazon.com/lambda/latest/dg/configuration-metadata-endpoint.html
3. AWS Lambda availability zone metadata announcement, posted March 19, 2026: https://aws.amazon.com/about-aws/whats-new/2026/03/lambda-availability-zone-metadata/
4. Powertools for AWS Lambda (TypeScript) Metadata utility: https://docs.aws.amazon.com/powertools/typescript/latest/features/metadata/