Update the pinned Wasmtime revision and thread MemoryKind through the limiter

[kmatasfp]

Picks up golemcloud/wasmtime#8 (GOL-424, GOL-425).

main already sits on 9f2c0b4a, which is one parent of #8's merge commit 252ab61f, so the lockfile moves by exactly that merge and nothing else. Only the rev strings change in Cargo.lock; cargo check --locked passes without rewriting it.

Limiter callbacks now carry a MemoryKind

memory_growing, memory_grown and memory_grow_failed take the kind of heap being grown. DurableResourceLimiter threads it through and filters in one place, so the three ResourceLimiterAsync impls (default, debug, test-utils) stay thin.

Golem's accounting covers guest linear memory only. MemoryKind::GcHeap growth is admitted without taking an admission grant and correspondingly never releases one.

This fixes a leak rather than adding information. Before #8, memory_growing fired for GC heap growth too, but the callback could not tell the two apart, so admit_unshared_memory_growth took a real grant through try_acquire_linear_memory and retained it. memory_grown then fired only for LinearMemory, so nothing ever resolved that grant. Every GC heap growth would have eroded host admission headroom until the store unloaded. That is GOL-425.

Counting GC heap into the same pool is not the fix. LinearMemoryTracker also drives the durable oplog grow hints, the per-agent memory meter, and replay reconciliation. That last one rules it out: initially_reserved_bytes derives from the persisted linear-memory size, and GC heap bytes have no counterpart there, so replay would under-prepay and re-acquire admission it already holds. If GC is ever enabled, the collector's heap wants its own pool.

Golem does not enable GC

create_wasmtime_config starts from Config::default() and never calls wasm_gc(true). Wasmtime's default set is WasmFeatures::WASM2 plus a handful of extras, and GC is a wasm 3.0 feature that is not among them, so no store allocates a GC heap and MemoryKind::GcHeap is unreachable today.

gc_proposal_is_disabled in golem-common/src/wasmtime_config.rs pins that: it compiles a module with a struct type and asserts the engine rejects it. Flipping wasm_gc(true) fails the test, which is the point, since the accounting decision above has to be revisited first.

Testing

• cargo check --locked --workspace --all-targets clean
• cargo clippy --workspace --all-targets clean
• cargo test -p golem-worker-executor --lib: 1119 passed
• cargo test -p golem-common --lib wasmtime_config: 2 passed, including the new GC assertion

[netlify]

✅ Deploy Preview for golemcloud canceled.

Name	Link
🔨 Latest commit	b1f9454
🔍 Latest deploy log	https://app.netlify.com/projects/golemcloud/deploys/6a8d4e4ebdb1940008171d45