Expose linear memory tracking APIs

[kmatasfp]

Summary

• enumerate every unique store linear-memory backing, including non-exported and aliased memories
• notify the resource limiter only after unshared memory growth commits successfully
• preserve memory kinds in pooled allocation while exposing safe backing identity and size APIs
• retain shared-memory enumeration for defensive detection, without shared-growth tracking because Golem does not support WebAssembly threads/shared memories

Behavior

Store::linear_memories walks instantiated core memories and returns one StoreMemory for each unique underlying backing. Memories do not need to be component exports to appear, and multiple imports, exports, or instance handles that alias the same backing are deduplicated. Callers can therefore reconcile a complete allocation total without relying on an export named memory or enabling guest debugging.

Unshared entries expose their current data_size through the store, while shared entries remain distinguishable for callers that need to reject or handle them separately. Pooled allocation preserves each memory's MemoryKind, so shared and unshared backings are classified consistently across on-demand and pooled instances.

For unshared memories, the resource limiter receives a committed-growth notification only after memory.grow has succeeded and the new size is installed. Failed growth and pre-instantiation allocation do not emit the callback. This lets embedders update aggregate accounting from the exact committed new_size - old_size delta without treating an attempted growth as allocated memory.

The fork does not add shared-memory growth observers or admission hooks. Shared backings remain enumerable only so embedders can identify them defensively; Golem disables WebAssembly threads/shared memory and rejects such components.