otelslog: fix shared kvBuffer append corrupting log attributes - #9229

kvBuffer.KeyValues returned append(b.data, kvs...). When cap(b.data) > len(b.data) this writes kvs into b.data's spare capacity and returns a slice aliasing that backing array. The buffer is shared across concurrent Handle calls (a Handler's group attributes, bridges/otelslog/handler.go:382), so two records append into the same backing array at the same time, which both races and corrupts each other's log attributes.

The fix clips b.data to its length so the append allocates a new backing array instead of writing into the shared spare capacity. This mirrors the existing slices.Clone use in Clone().

Validation (local, Go 1.26):

• go test -race ./... passes in bridges/otelslog.
• Both new tests fail on the pre-fix code: TestKVBufferKeyValuesDoesNotAliasBackingArray (deterministic) fails, and TestKVBufferKeyValuesConcurrent reports a DATA RACE under -race.
• go vet, gofmt, and golangci-lint v2 are all clean.

Allocation note: the previously-buggy case where kvs fit in b.data's spare capacity now allocates a new backing array (needed for correctness); the empty-kvs path stays zero-alloc via slices.Clip.

related: #9046