Scope tracing export-error deduplication to OTLP exporter failures

## Summary

Scope OpenTelemetry export-error deduplication to OTLP trace exporter failures rather than relying on a process-wide `otel.SetErrorHandler` replacement.

## Rationale

`tracing/tracing.go` currently installs a global OpenTelemetry error handler to suppress repeated tracing export-failure logs. Although it delegates to the previously configured handler, it cannot distinguish OTLP exporter errors from unrelated OpenTelemetry errors. An unrelated error can therefore emit the tracing collector-unreachable message and consume the one-time logging state.

## Affected area

- `tracing/tracing.go`
- OpenTelemetry error handling and OTLP trace exporter integration

## Required changes

- Move or redesign deduplication so it applies only to OTLP trace exporter failures.
- Preserve retries by the exporter.
- Do not alter handling or logging semantics for unrelated OpenTelemetry errors.
- Preserve any pre-existing OpenTelemetry error handler behavior without relying on a global latch for exporter-specific state.
- Add focused tests covering repeated exporter failures and unrelated OpenTelemetry errors.

## Acceptance criteria

- Repeated failures from the configured OTLP trace exporter produce at most one MeshKit collector-unreachable log per intended suppression scope.
- Unrelated OpenTelemetry errors neither produce the collector-unreachable log nor prevent the first exporter-failure log.
- Existing error handlers continue to receive errors as intended.
- Tests cover the exporter-specific and unrelated-error paths.

## Backlinks

- Deferred from PR #1070: https://github.com/meshery/meshkit/pull/1070
- Review discussion: https://github.com/meshery/meshkit/pull/1070#discussion_r3637324009
- Requested by: @uzairhameed