Consider a MaterializingResolver compositional layer for local resolver stacks

Context

The local resolver providers use a compositional pattern: WasmResolver → RecoveringResolver → PooledResolver. Materialization suspend/resume logic currently lives in the provider/caller layer across all implementations (Go, Java).

Suggestion

Add a MaterializingResolver as a composable layer in the resolver stack, wrapping the pooled resolver and a MaterializationStore:

WasmResolver → RecoveringResolver → PooledResolver → MaterializingResolver

This would apply to all providers that use the compositional pattern.

Benefits

• Single responsibility — each layer does exactly one thing; the provider focuses on OpenFeature lifecycle (init, shutdown, scheduling)
• Testability — materialization suspend/resume can be tested in isolation without standing up the full provider
• Reusability — the resolver stack becomes self-contained and usable outside the provider (e.g. proxy services like FlagResolverService)
• Consistency — materialization handling is defined once per language rather than duplicated across different callers

Trade-offs

• Adds one more layer to the composition chain
• The LocalResolver interface stays materialization-unaware — the MaterializingResolver handles ResolveProcessResponse suspend/resume internally and exposes a simpler resolve contract to callers

The issue names no files or tests. Start by locating the Go and Java local resolver providers, their PooledResolver composition, and the existing MaterializationStore and suspend/resume handling. Compare those paths before deciding whether the proposed MaterializingResolver can be shared; done means an agreed design and implementation that preserves the described resolver behavior.