perf: cache deserialized feature definitions in FeatureEvaluator

[elliotmjackson]

Deserializing a feature definition dominates evaluation cost. Profiling a caller that evaluates ~50 features per request put 44% of process CPU in evaluateFeature, three quarters of it inside Gson.fromJson — more than every database query on the endpoint combined.

The parsed Feature depends only on the feature JSON, never on the context or attributes, so it is re-derived for nothing. Callers that build a GrowthBook per evaluation — the normal shape when the context carries per-request attributes — pay it on every single call.

Cache the parsed definition, keyed by feature name and scoped to one features document identified by reference. A new features object (an API refresh, or setFeatures) replaces the map wholesale. Reference identity is deliberate: JsonObject.equals walks the whole tree and would cost as much as the parse it avoids. The cache is static because a FeatureEvaluator is created per GrowthBook, so a per-instance cache would never be reused by those callers.

Entries are safe to share: Feature exposes only final fields and nothing in evaluation mutates a feature or its rules.

Measured on the calling service, API pinned to 2 cores to remove load-generator contention: 104 -> 220 rps at 100% success, median latency 17ms -> 9.9ms. Roughly double the throughput per core.

The existing conformance suite passes unchanged (132 tests), plus 4 new tests covering cache scoping and invalidation.