[bug] ContextProvider thread-safety: doc claim doesn't match code

[robbyt]

Summary

README.md:103 advertises thread-safe per-request data via ContextProvider, but platform/data/contextProvider.go:62-91 does an unsynchronized read-modify-write on the data map pulled from the parent context.

Since each call returns a derived context (via context.WithValue), the context value chain is safe — but two goroutines that start from the same parent context with overlapping enrichments can produce a "last writer wins" outcome where one goroutine's data is silently dropped.

This is fine if the documented usage is "thread one context per request, sequentially", but the README's current phrasing doesn't carve out that constraint.

Proposal

Either:

• Narrow the doc claim: "context-derivation pattern; each request must thread its own derived context sequentially." Add a code comment on ContextProvider.AddDataToContext explaining the constraint.
• Or: actually serialize the merge. The cleanest spot is to store a sync container in the context value rather than a bare map, but that has its own ergonomic costs.

Tests

Add a go test -race test that runs N goroutines concurrently calling AddDataToContext against the same parent context and verifies whichever behavior we land on.

Files

• platform/data/contextProvider.go:62-91
• README.md:103
• New: a race test in platform/data/contextProvider_test.go