feat(logger): add configurable structured log pipelines

[chrisadubois]

COMPLETES # N/A - proof of concept for configurable SDK log pipelines

This pull request addresses

The Web Client needs to route SDK logs through its own OpenTelemetry runtime without making OpenTelemetry a dependency or default behavior of webex-js-sdk. The SDK should own the stable record contract, formatting boundary, and configurable transport fanout while preserving its existing console and buffered upload behavior by default.

by making the following changes

• Stores a versioned, redacted structured record alongside the existing legacy log representation.
• Publishes a closed logRecordSchema v1 contract, shared attribute keys, controlled initiator and trigger taxonomies, and a 128-attribute limit.
• Generates readable event and operation instance IDs such as joinMeeting_<uuid>.
• Validates native OpenTelemetry identifiers without changing their required format:
  • trace IDs remain 32 lowercase hexadecimal characters
  • span IDs remain 16 lowercase hexadecimal characters
• Adds optional logger.formatter(record) and logger.transports[].write(record) contracts.
• Treats an explicit transport array as the complete output configuration:
  • omitted transports preserves the existing SDK console and buffer defaults
  • [transport] sends admitted records only to that transport
  • [] intentionally discards admitted records
• Formats each record once before fanout and isolates formatter or transport failures from SDK operation.
• Exports an OpenTelemetry-compatible formatter without importing the OpenTelemetry runtime.
• Preserves the existing formatLogs() and incremental submitLogs serialization when custom transports are omitted.
• Keeps the structured client-log entry point internal to the logger plugin for named events, event IDs, and scalar attributes.
• Redacts Basic/Bearer credentials and existing sensitive patterns before records reach any transport.

Change Type

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Tooling change
• Internal code refactor

The following scenarios were tested

• yarn workspace @webex/plugin-logger test:unit - 79 tests passed.
• yarn workspace @webex/internal-plugin-support test:unit - 43 tests passed on the earlier transport increment, covering legacy log submission compatibility.
• yarn workspace @webex/plugin-logger build - package built successfully for local SDK_DIR integration.
• yarn workspace @webex/plugin-logger test:style - no errors; 8 existing JSDoc warnings.
• Targeted Prettier checks passed for every changed file.
• Verified default behavior, one or multiple transports, an empty transport array, log-level admission, formatter-once fanout, formatter failures, transport failures, logToBuffer, legacy full/diff serialization, structured schema fields, taxonomy validation, attribute limits, readable event/operation IDs, strict native trace/span ID validation, and credential redaction.
• Linked this branch into webex-web-client through SDK_DIR.
• Playwright positive case passed with logs and traces enabled, validating the SDK transport, official batch pipelines, OTLP envelopes, Basic Auth header construction, native trace/span IDs, readable event/operation IDs, shared log-span correlation, and clock/taxonomy metadata.
• Playwright negative case passed with logs and traces disabled, validating zero collector requests and preservation of the existing SDK log buffer.
• Earlier manual integration validation sent linked-app log and trace batches directly to the integration collector with HTTP 200 responses and no CORS errors.

POC boundaries and production follow-ups

• OpenTelemetry remains application-owned and opt-in; this SDK package does not add an OpenTelemetry runtime, provider, processor, exporter, endpoint, or credential.
• Schema evolution needs an owner, compatibility policy, generated documentation, and backend contract tests before v1 is treated as permanent.
• High-cardinality IDs must remain searchable attributes rather than default indexed dimensions; event and span names must remain stable and low-cardinality.
• Attribute value length limits, PII classification, retention, and backend index allowlists still need agreement with the collector/storage owners.
• Async transport backpressure and delivery guarantees belong to each transport implementation. The SDK deliberately does not add a second queue on top of the OpenTelemetry batch processor.

The GAI Coding Policy And Copyright Annotation Best Practices

• GAI was not used (or, no additional notation is required)
• Code was generated entirely by GAI
• GAI was used to create a draft that was subsequently customized or modified
• Coder created a draft manually that was non-substantively modified by GAI (e.g., refactoring was performed by GAI on manually written code)
• Tool used for AI assistance (GitHub Copilot / Other - specify)
  • Github Copilot
  • Other - Codex
• This PR is related to
  • Feature
  • Defect fix
  • Tech Debt
  • Automation

I certified that

• I have read and followed contributing guidelines
• I discussed changes with code owners prior to submitting this pull request
• I have not skipped any automated checks
• All existing and new targeted tests passed
• I have updated the configuration and schema documentation accordingly

---

⚠️ AI Assisted Content 🤖

[aws-amplify-us-east-2]

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-5124.d3m3l2kee0btzx.amplifyapp.com