[LOGS] Pass resolved context to LogRecordProcessor::OnEmit unconditionally

[om7057]

Summary

Split out of #4309 per review: EventToSpanEventBridgeProcessor needs the resolved trace Context at OnEmit time to reach the live Span it bridges an event onto. That turned out to be a public API surface for both logs::Logger and sdk::logs::LogRecordProcessor, so it gets its own PR with its own analysis before the bridge processor depends on it. #4309 will be rebased on top of this once it merges, and cut down to just the bridge processor + declarative config.

The bug: Logger::EmitLogRecord(record) re-derived the resolved context from RuntimeContext::GetCurrent() (ambient) instead of reusing whatever context had already been resolved for this record, so an explicitly supplied context could be silently dropped in favor of whatever span happened to be ambient at emit time.

Design: resolve context once and always pass it to OnEmit, no per-processor opt-in flag (an earlier draft of this had one; removed per @dbarker's review that it's unnecessary API surface once the cost of passing it through is understood -- see below).

The 7 use cases

Context context = trace::SetSpan(original_context, my_span);

1. EmitLogRecord("msg", context) -- explicit Context.
2. EmitLogRecord("msg") -- implicit ambient.
3. CreateLogRecord(); EmitLogRecord(r) -- no context anywhere.
4. CreateLogRecord(context); EmitLogRecord(r) -- explicit to Create only.
5. EmitLogRecord("msg", span_context) -- bare SpanContext.
6. EmitLogRecord("msg", trace_id, span_id, flags)
7. CreateLogRecord(span_context); EmitLogRecord(r)

Cases 1/2/5/6 already resolve context inside EmitLogRecord(args...) regardless of any processor (needed for the Enabled() filter chain) -- passing it through to processors costs nothing new.

Cases 3/4/7 use the two-step create-then-emit pattern, which the Logger has no way to carry an explicit context across: the resolved Context (and any live Span it owns) isn't retained anywhere between the two calls.

Two mechanisms for closing that gap were considered and rejected:

• Storing the Context on the Recordable between the two calls. BatchLogRecordProcessor buffers a Recordable for up to scheduled_delay_millis (default 5000ms) before export, so a Context stashed there would keep its Span alive for that whole window -- an unrelated subsystem silently extending a span's lifetime.
• Reconstructing a SpanContext from the record's own stamped fields. The base Recordable interface is write-only (no GetTraceId/GetSpanId), so recovering it generically would need either an unsafe downcast or expanding that interface for every processor's own Recordable implementation.

So: case 3 (no explicit context ever given) resolves ambient fresh at emit time -- spec-correct, since ambient-at-emit-time is the right answer when nothing explicit was supplied. Cases 4 and 7 (explicit context/span_context given to Create only) are a documented, tested limitation: the plain EmitLogRecord(record) call sees ambient, not the original context. Callers who need the processor to see the same context they gave CreateLogRecord must call EmitLogRecordWithContext(record, context) instead, re-passing the context they already have in hand. Case 7 isn't actually a regression versus case 5/6: a bare SpanContext never carried a live Span to begin with, so the ids delivered via EmitLogRecordWithContext are fully compliant for that case.

Changes

• api/include/opentelemetry/logs/logger.h (ABI v2): added EmitLogRecordWithContext(record, resolved_context), a new virtual with a default that forwards to EmitLogRecord(record) so existing Logger implementations keep compiling unchanged. Distinct name (not an EmitLogRecord() overload) so a derived class overriding only the record-only overload can't hide it -- same reasoning as the LogRecordProcessor side below. EmitLogRecord(args...) now calls it with the context_or_span it already resolved, instead of discarding that resolution. Extracted the per-argument stamping loop (previously duplicated) into a shared StampLogRecordFields() helper.
• sdk/include/opentelemetry/sdk/logs/processor.h: added OnEmitWithContext(record, context), unconditional (no opt-in flag), default forwards to OnEmit().
• sdk/src/logs/logger.cc: EmitToProcessor() always calls OnEmitWithContext(). When no context was ever supplied to this specific call (the plain EmitLogRecord(record) path), it resolves ambient fresh as a best-effort fallback.
• sdk/{include,src}/logs/multi_log_record_processor.{h,cc}: fans OnEmitWithContext() out to every child processor.

Verified unaffected: exporters/etw/include/opentelemetry/exporters/etw/etw_logger.h, the one real production logs::Logger subclass besides the SDK's own -- it only overrides the record-only EmitLogRecord(), not EmitLogRecordWithContext, so it keeps its existing ambient-fallback behavior unchanged. No production LogRecordProcessor subclass exists outside sdk/src/logs/ (checked exporters/otlp, elasticsearch, ostream, opentracing-shim).

Test plan

• sdk/test/logs/logger_sdk_test.cc: ContextCapturingProcessor + one test per case above, including the two documented-limitation tests for cases 4/7 and their EmitLogRecordWithContext-fixed counterparts.
• Three tests pin the exact RuntimeContext::GetCurrent() call count for cases 1/2/3 (0, 1, and 2 respectively), so the cost claim above is verifiable rather than asserted.
• Full ctest green in a from-scratch ABI v2 build (-DWITH_ABI_VERSION_1=OFF -DWITH_ABI_VERSION_2=ON) -- 904/904.
• Full ctest green in the existing ABI v1 build -- 1367/1367.
• clang-format, doxygen docs/public/Doxyfile.lint, misspell all clean.

[codecov]

Codecov Report

❌ Patch coverage is 97.56098% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 83.21%. Comparing base (8074e35) to head (faca99f).

Files with missing lines	Patch %	Lines
sdk/src/logs/logger.cc	94.45%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4421      +/-   ##
==========================================
- Coverage   83.22%   83.21%   -0.01%     
==========================================
  Files         521      521              
  Lines       20404    20443      +39     
==========================================
+ Hits        16980    17010      +30     
- Misses       3424     3433       +9     

Files with missing lines	Coverage Δ
api/include/opentelemetry/logs/logger.h	82.48% <100.00%> (+1.37%)	⬆️
sdk/include/opentelemetry/sdk/logs/processor.h	100.00% <100.00%> (ø)
sdk/src/logs/multi_log_record_processor.cc	86.46% <100.00%> (-10.01%)	⬇️
sdk/src/logs/logger.cc	94.12% <94.45%> (ø)

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[om7057]

@dbarker small reminder on this one!

[om7057]

@dbarker I was unnecessarily rushing through this PR; I should have taken my time to split it out from this: #4309
Apologies for that; I'll wait and verify all the changes myself one by one, instead of just trying to get the changes merged.