fix(transform): don't panic on absent optional OTLP fields

[vito]

Three functions in transform.go dereferenced a pointer that the OTLP proto marks optional, so converting a perfectly valid payload that simply omits the field panicked with a nil pointer dereference.

• ResourceFromPB read pb.Attributes directly. resource is optional on ResourceSpans, ResourceLogs and ResourceMetrics — "if this field is not set then no resource info is known" — so a payload without one crashed. This reached users through SpansFromPB (via readOnlySpan.Resource()), ReexportLogsFromPB and ResourceMetricsFromPB. Now uses the generated nil-safe getter, pb.GetAttributes().
• LogValueFromPB switched on v.Value, which panics when v is nil. body is optional on LogRecord, and an attribute-only record — one carrying its data in attributes rather than log text — is legal and common; ReexportLogsFromPB calls LogValueFromPB(rec.GetBody()) unconditionally. Now returns log.StringValue(""), which is what an absent body means to every consumer and matches what a body explicitly set to "" already produced. This also covers logKeyValue, which passes v.GetValue().
• attrValue had the identical bug on the span/attribute side, hit by a KeyValue whose value field is absent. Fixed the same way, returning an empty string value rather than falling into the default branch's UNHANDLED ATTR TYPE logging — absent is not unhandled, it is absent.

All three guards sit ahead of the type switch, so no payload that does set these fields changes behaviour. This follows the existing pattern in the file: InstrumentationScopeFromPB and StatusCodeFromPB already return a zero value for nil.

Tests

Three regression tests in transform_test.go, matching the existing testify style:

• TestSpansFromPBNilResource — ResourceSpans{Resource: nil} with one span, asserting .Resource() returns a non-nil resource with no attributes.
• TestReexportLogsFromPBNilResourceAndBody — nil resource, nil body, two attributes; asserts the exported record comes through with an empty body and both attributes intact.
• TestAttributesFromProtoNilValue — a KeyValue with a nil Value converts to an empty STRING attribute with its key preserved.

Each one panics on its own with the fix reverted. Reverting only the LogValueFromPB guard still makes the log test panic, confirming it covers the nil-body case independently rather than just tripping the resource bug first.

go test ./... and go vet ./... both pass.

🤖 Generated with Claude Code

[vito]

🤖 Corroboration from the consumer side, in case it's useful for the review: both of the first two were hit as real SIGSEGVs (not hypotheticals) while building a trace-import path in dagger/dagger, feeding a hand-built OTLP capture through SpansFromPB and ReexportLogsFromPB:

• ResourceFromPB — via readOnlySpan.Resource(), on a ResourceSpans with no resource.
• LogValueFromPB — via ReexportLogsFromPB, on an attribute-only LogRecord with no body.

Worth noting the second one isn't only reachable from new code: engine/server/telemetry.go's POST /v1/logs handler passes a decoded request straight to ReexportLogsFromPB, so any client posting a body-less record panics that handler today. Every in-repo producer sets an explicit empty-string body, which is presumably why nobody has tripped it.

attrValue is the one I hadn't spotted, and it looks like the sharpest of the three: AttributesFromProto already skips nil elements but passes a.Value through unchecked, so a KeyValue with a key and no value — exactly what a re-encoder emits for a value it can't represent — reaches the deref. Returning an empty value rather than falling into UNHANDLED ATTR TYPE also seems right; "absent" and "unhandled" deserve different answers.