bug: CompositeProvider.AddDataToContext silently swallows provider errors on partial success

[robbyt]

Summary

CompositeProvider.AddDataToContext returns a nil error even when some non-static providers failed to store the data, as long as at least one succeeded. The collected errors are dropped with no log, and the failing provider's data is silently absent from the resulting context.

Root cause

platform/data/compositeProvider.go:128-149:

errs = append(errs, fmt.Errorf("error from provider %d: %w", i, err))
continue
...
// If all non-StaticProvider providers failed, return an error
if totalCount > 0 && successCount == 0 && len(errs) > 0 {
	return ctx, errors.Join(errs...)
}
// Return the most updated context with no error
return finalCtx, nil

Errors surface only when every non-static provider fails (successCount == 0). With one or more successes they are discarded. The failing provider's partial context is also dropped (continue without assigning finalCtx), so the caller sees success while that provider stored nothing.

Repro (confirmed): NewCompositeProvider(failingProvider, NewContextProvider(constants.EvalData)).AddDataToContext(ctx, data) returns err == nil even though failingProvider rejected the data.

Secondary case

NewCompositeProvider() (no providers, or only nil entries) has staticCount == totalCount == 0, so it returns the original context and a nil error — the caller's data vanishes. AddDataToContextHelper errors on a nil provider; this path does not.

Impact

Medium — downstream evaluation silently sees stale or missing data, with no error or log to diagnose it.

Fix

Return errors.Join(errs...) alongside the most-updated context whenever len(errs) > 0, regardless of successCount, and return an explicit "no providers configured" error for the empty/all-nil case. Add tests for partial-failure and empty-composite scenarios.