fix: Cache config metadata per sdk key per config

[JamieSinn]

This was over-read from and caused a memory allocation spike that isn't really required as part of the normal operation of the SDK. Caching this once per config write is a more reasonable memory usage path without requiring a whole new release of WASM.

This should resolve #195

[Copilot]

Pull request overview

This PR reduces repeated WASM-side and Java-side allocations by caching the config metadata JSON per SDK key, so DevCycleLocalClient.getMetadata() no longer re-reads metadata from the WASM module on every variable evaluation. This aims to prevent the observed RSS growth/memory spike described in issue #195.

Changes:

• Cache config metadata on storeConfig writes.
• Add a read-through cache in getConfigMetadata to avoid repeated WASM calls.
• Minor Java generics modernization (new HashMap<>()).

Suppressed comments (1)

src/main/java/com/devcycle/sdk/server/local/bucketing/LocalBucketing.java:392

• getConfigMetadata is the only public method in this class that is not synchronized, but it calls getSDKKeyAddress and interacts with the WASM store/linker and mutable HashMaps. Concurrent variable evaluations can call this method from multiple threads and race with storeConfig, which can corrupt the internal maps/WASM interactions. Make this method synchronized and avoid the containsKey()+get() double lookup.

    public String getConfigMetadata(String sdkKey) {
        if (configMetadataCache.containsKey(sdkKey)) {
            return configMetadataCache.get(sdkKey);
        } else {
            int sdkKeyAddress = getSDKKeyAddress(sdkKey);

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[JamieSinn]

The config unit test only checks there is no thrown exceptions - nothing else.