fix(laminar): bound diagnostic span and export memory
Large diagnostic strings and count-only queues let tracing consume excessive worker and control-plane memory. This bounds diagnostic text to 16 KiB, encoded records to 64 KiB, uploads to 1 MiB, and pending diagnostics to 4 MiB or 512 records, preserving original task input and marking truncation. Verification: 14 tests and the configured monorepo typecheck pass, covering UTF-8 bounds, identity and usage preservation, queue recovery, real HTTP 413 without retry, and an attribute-key collision reproduced red then fixed green (evidence). Release this sender and update the Cloud worker pin before deploying the receiver change; older in-flight workers and chunked connection-reset behavior still need compatibility verification. Sender tests also verify timeout recovery, schema preservation, and near-limit encoded uploads; staging deployment follows the released worker pin.
Summary by cubic
Bounds tracing memory usage so large diagnostic strings and stalled exporters can no longer exhaust worker and control-plane memory.
- Caps diagnostic text at 16 KiB, per-record encoding at 64 KiB, uploads at 1 MiB, and queued diagnostics at 4 MiB or 512 records.
- Marks truncated spans with
bcode.telemetry.truncatedwhile preserving the original task input. - Drops over-budget spans instead of queuing them; the queue drains normally once the exporter resumes.
- Releases the export budget when an export times out, and ignores late exporter callbacks so a batch can never be double-counted.
- Adds
@opentelemetry/otlp-transformerand@opentelemetry/resourcesand reduces the export timeout from 30 s to 10 s.
Draft with local synthetic test evidence only; nothing deployed. Requires the Cloud worker pin to be updated before deploying the companion receiver change.