What specific problem does this solve?

A couple power users would like to be able to collect the OpenTelemetry traces with our own custom collector endpoints. This would allow us to have full visibility into model/inference activity. This would allow us greater ability to fine-tune prompts/modes/tools/compare modes/run custom online evals/etc.

Additional context (optional)

Current Roo OTEL function: https://github.com/RooCodeInc/Roo-Code/blob/main/packages/telemetry/src/BaseTelemetryClient.ts

Roo Code Task Links (Optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear impact and context

Interested in implementing this?

• Yes, I'd like to help implement this feature

Implementation requirements

• I understand this needs approval before implementation begins

How should this be solved? (REQUIRED if contributing, optional otherwise)

Currently Roo already supports OTEL and collects data for internal use. I believe OTEL supports sending to multiple endpoints out of the box. Base implementation would be:

1. UI to add additional endpoints
2. Add functionality to existing OTEL service to add additional endpoints to the OTEL collector array. If the array population ran only on startup and required a VSCode reboot when changes are made in the UI that would be fine. These changes should not be frequent.

Ref: #6547

How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)

Given Roo is running normally
When a user adds a custom OTEL endpoint
Then Roo sends traces to all endpoints
And all other existing functionality is not affected

Given a user has added a custom endpoint
When a user removes the custom endpoint
Then Roo sends traces to the original internal endpoint
And all other existing functionality is not affected

Technical considerations (REQUIRED if contributing, optional otherwise)

1. Need to confirm how OTEL supports multiple trace collector endpoints
2. Need to confirm how UI and OTEL service architecture could connect
3. Need to measure added latency

Trade-offs and risks (REQUIRED if contributing, optional otherwise)

Review implementation to ensure there is no significant new latency