fix(laminar): bound diagnostic span and export memory

[sarath-menon]

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.truncated while 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-transformer and @opentelemetry/resources and 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.

^{Written for commit 12a406f. Summary will update on new commits.}

[cubic-dev-ai]

All reported issues were addressed across 7 files

<sub>Heads up: you’re close to your flex budget. Increase your flex budget so reviews don’t pause.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 6 files (changes from recent commits).

<sub>Heads up: you’re close to your flex budget. Increase your flex budget so reviews don’t pause.

Fix all with cubic | Re-trigger cubic</sub>

[sarath-menon]

Verified in shared staging after merging BrowserCode #164 and Cloud #6142, #6143, #6140.

• Sender release: v0.1.21-telemetry.1; release workflow https://github.com/browser-use/browsercode/actions/runs/36034973578 succeeded. Normal worker staging deployment https://github.com/browser-use/cloud/actions/runs/36039438585 succeeded with runtime version 252 and verified binary checksum.
• Receiver merge: 2326c2faf0bee0edff6a4404559002ad4b2816e5; normal staging deployment https://github.com/browser-use/cloud/actions/runs/36041573153 succeeded.
• Owned live v4 run c59559e5-639c-446b-b3de-0d696ae9dc8a completed. Actual tool output confirmed the released sender version, HTTP 413 for a 1,048,577-byte telemetry upload, and HTTP 200 for the following valid protobuf upload. A 40,000-character tool result remained intact. Browser/session/workspace cleanup succeeded; cost $0.010173.
• Existing staging API suite: 61 passed, https://github.com/browser-use/cloud/actions/runs/36042330959 . This suite covers v2/v3; the owned v4 check above separately verifies this change.
• Backend CI: 7,899 passed, 5 skipped. Focused receiver tests: 34 passed. Sender tests: 14 passed on release Bun 1.3.14; 17 typecheck tasks passed.

Limits: the local memory benchmark is not a staging RSS measurement; these checks do not establish that every historical OOM cause is eliminated. Production transport, mixed-version rollout, and production memory behavior still need release monitoring. No production deployment or manual AWS changes were made.