sdk/log: Count limit-suppressed exception attributes as dropped

[pellared]

Description

The Logs SDK undercounts DroppedAttributes when exception.message or exception.type is omitted because the configured LogRecord attribute-count limit has no remaining capacity.

The exception derivation path computes the remaining capacity and jumps to flush when another derived attribute cannot fit. Only attributes that fit are added through addAttrs; the omitted exception attributes never pass through addDropped (implementation). Ordinary attributes omitted by the same limit are counted correctly by Record.AddAttributes (implementation).

The Stable ReadableLogRecord specification says counts for attributes dropped due to collection limits MUST be available to exporters (specification). It permits considering attribute limits while generating exception attributes, but does not explicitly exempt attributes skipped before materialization from dropped-count accounting (exception generation note). Under the natural reading, a known, derivable attribute omitted because the limit has no capacity is dropped due to that limit.

Related compliance audit: #8547.

Environment

• OS: Linux
• Architecture: x86_64
• Go Version: go1.26.4
• opentelemetry-go version: 0de413a318cb52629baefb89a1554a905e105aa3

Steps To Reproduce

1. Create a Logs LoggerProvider with an attribute-count limit of zero and a processor that captures emitted records.
2. Emit a record containing two caller-provided attributes and an error with derivable message and type.
3. Read DroppedAttributes from the resulting SDK record.
4. Observe that it returns 2, counting only the caller-provided attributes. The existing option and environment tests encode this behavior (option test, environment test).

Expected behavior

DroppedAttributes should return 4: two caller-provided attributes plus the derivable exception.message and exception.type omitted because of the count limit. Partial-capacity cases should likewise count each exception attribute omitted specifically because no capacity remains.

If the intended specification interpretation is that an exception attribute suppressed before materialization is not dropped, document that interpretation and close this issue without an implementation change.

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}