fix(tracing): make trace finish idempotent

[sylvesterkaczmarek]

Summary

• make TraceImpl.finish() notify processors at most once
• preserve the ability to reset a trace context on a later finish(reset_current=True) call
• align trace lifecycle behaviour with the existing idempotent span finish path

Calling finish() more than once currently emits duplicate on_trace_end events, which can enqueue and export the same trace multiple times. The finished state is recorded after the processor callback succeeds, before any optional context reset.

Test plan

• added focused regression coverage in tests/test_trace_finish_idempotent.py
• GitHub Actions

Issue number

N/A

[seratch]

I confirmed that calling TraceImpl.finish() twice currently invokes a custom processor's on_trace_end callback twice. However, the default BatchTraceProcessor queues traces on on_trace_start and does no work in on_trace_end, so the PR does not demonstrate the claimed duplicate export on the normal SDK path.

The documented lifecycle is either the context manager or one balanced manual start()/finish() pair. Please provide a concrete supported path or integration where the same trace is finished twice and the duplicate callback causes an observable consequence. Without that evidence, I do not think this additional lifecycle state is justified, so I would close this PR for now.