Clarify metadata propagation in OFREP provider guidelines

Following the Slack discussion, I suggest explicitly defining how OFREP response metadata reaches OpenFeature flagMetadata. At Confidence, we want to carry an opaque resolve token through metadata so an after hook can report exposure when a cached flag is evaluated.

I suggest updating Evaluation in the dynamic provider guidelines, and Initialization, Evaluation, Polling, and Change context in the static provider guidelines, to specify:

• Preserve all valid per-flag metadata, including custom vendor keys, in resolution flagMetadata.
• Keep cached metadata associated with its value: retain it on 304, replace it on 200, and clear old entries when omitted from the replacement.

Suggested wording for per-flag propagation to start a discussion:

Providers MUST preserve per-flag OFREP metadata in OpenFeature resolution flag metadata, retaining keys, values, and primitive types. Static providers MUST preserve this association when caching and updating evaluations.

I would also like to define how bulk-level metadata is exposed to applications and hooks, including whether it is merged into per-flag metadata and which keys take precedence. Not sure if we want to take that discussion in the same issue?

Are there existing implementations or cache semantics that would make these requirements problematic?

AI-assisted

Read guideline/dynamic-context-provider.md at Evaluation and guideline/static-context-provider.md at Initialization, Evaluation, Polling, and Change context. Clarify per-flag metadata preservation and static-provider cache behavior for 304 and 200 responses, then determine whether bulk-level metadata belongs in this issue and how it is exposed.