feat(store-memory): implement in-process memory store

[jfallows]

Summary

Closes #1667

Implements the memory store type in a new runtime/store-memory module. This is the default store for single-instance deployments and development environments.

• MemoryStoreFactorySpi — registers the memory type name
• MemoryStore — shared ConcurrentHashMap-backed state, created once per store instance
• MemoryStoreContext — per-worker context supplying MemoryStoreHandler
• MemoryStoreHandler — delegates all operations inline to MemoryStore (synchronous, no thread switch)
• specs/store-memory.spec/ — schema patch registering memory as a valid store type
• MemoryStoreHandlerTest — unit tests covering all 5 operations and TTL expiry

Behaviour

• All StoreHandler operations invoke completion synchronously on the calling thread
• putIfAbsent uses ConcurrentHashMap.putIfAbsent — atomic
• getAndDelete uses ConcurrentHashMap.remove — atomic
• Entries carry an expiry timestamp; get returns null for expired entries (lazy expiry)
• Intentionally unbounded — no eviction; entries are retained until TTL expiry or explicit removal

Test plan

• ./mvnw install -DskipITs -pl runtime/store-memory -am compiles without errors
• ./mvnw test -pl runtime/store-memory — all unit tests pass
• A zilla.yaml with stores: type: memory parses without schema error

[jfallows]

Suggested change

	if (existing == null || existing.expired())
	{
	if (existing != null && existing.expired())
	{
	entries.replace(key, existing, newEntry);
	}
	return null;
	}
	return existing.value;
	if (existing != null && existing.expired())
	{
	entries.replace(key, existing, newEntry);
	existing.value = null;
	}
	return existing != null ? existing.value : null;

[jfallows]

Suggest using record instead.

[jfallows]

Instead pass this::supplyEntries and rename attach to supplyEntries, also make it private.
Then MemoryStoreContext can have a parameter of type LongFunction<ConcurrentMap<String, MemoryEntry>>.

[jfallows]

Suggest renaming this as storage instead of entries.

[jfallows]

Use the normal pattern to create the handler, via MemoryStore supplyContext(...), attach(StoreConfig).

[jfallows]

Do we need AtomicReference<String> in these tests, or is MutableReference<String> sufficient?

[jfallows]

There can be multiple contexts per store, one context per engine worker, so removing the entries from storage on the first call to detach is not correct.

Instead we need a reference count on the storage, and only remove when it reaches zero.

Perhaps the lambdas should be called acquireEntries and releaseEntries instead?