fix(tracing): register exporters added after initialization

[feng-95]

Dependency

• fix(tracing): trust preconfigured provider for APMPlus #813 has been squash-merged as ffbf295.
• The frozen fix(tracing): trust preconfigured provider for APMPlus #813 branch remains at 387a856 and was not modified.
• feat/exporter was rebased onto merged origin/main; the only PR increment is 018cc56dbad7e8fcf192276c7874cd3c252f194d.
• This Draft PR is now mergeable against main.

Summary

• Add BaseExporter.register(provider) to attach an exporter processor and resource attributes exactly once per provider.
• Add OpentelemetryTracer.add_exporter() so exporters enabled after tracer initialization are registered immediately.
• Route environment-driven APMPlus, CozeLoop, and TLS exporters through the registration path.
• When a global provider is already configured, retain APMPlusExporter and its meter uploader but skip only its trace processor registration. The external provider remains responsible for trace delivery.
• Avoid creating a second APMPlus exporter when one was supplied manually and ENABLE_APMPLUS=true is also set.

Root cause

Appending an exporter to tracer.exporters after the global TracerProvider had already been initialized did not attach the exporter span processor. The exporter object existed, but it could not receive or upload spans. The earlier global-provider fix also removed the APMPlus exporter object entirely, which prevented its metrics path from being retained.

Validation

• pytest -q tests/test_tracing.py tests/test_tracing_content.py — 26 passed after the rebase.
• 8-case ENABLE_APMPLUS × preconfigured provider × manual exporter unit-test matrix passed.
• Ruff 0.11.12 check and format passed.
• git diff --check passed.
• Full local pre-commit reached the gitleaks bootstrap but the machine old Go toolchain cannot parse gitleaks go 1.23.0 / toolchain directives; GitHub CI remains the authoritative full-hook check.

End-to-end matrix

Scenario	Trace route	APMPlus cloud span / unique	gen_ai_chat_count
ENABLE_APMPLUS=true, no global provider	direct APMPlus	4 / 4 (925974450246f25a786453722f2fa1c6)	1
manual APMPlusExporter, no global provider	direct APMPlus	4 / 4 (876a1f163e75e5c879553c5729b90e19)	1
env enabled, programmatic global provider	localhost:4318 only	4 / 4 (24d0a0f3d2fecd504bd7645cecb7c1ff)	1
manual exporter, programmatic global provider	localhost:4318 only	4 / 4 (d6a3bcd406bd871962d54fac9682a3c9)	1
env + manual exporter, programmatic global provider	localhost:4318 only	4 / 4 (dfdd3f92dcf50ac26b5efbe6b741a27f)	1
opentelemetry-instrument + env enabled	localhost:4318 only	5 / 5 (50bc24477fb2f86f10a8c120178b3dff)	N/A

The local OTLP relays observed zero duplicate (trace_id, span_id) pairs in every scenario. For each metrics-enabled scenario, the APMPlus time series had current=min=max=1, including after explicit force_flush() and process shutdown.

Known boundary

opentelemetry-instrument installs a zero-reader global MeterProvider even with OTEL_METRICS_EXPORTER=none. The #810 meter uploader cannot replace it, so the last scenario has no metrics. This is accepted for #810 and is fixed separately by #814.

Test report

• Feishu: https://bytedance.larkoffice.com/docx/FTK1dAce2oq3EDxxKDIcWJN1nAd
• Local Markdown: /Users/bytedance/go/src/code.byted.org/byteapm/docs-feng/veadk-python/VeADK_Exporter_Register_增量测试报告.md