Consider skipping GC heap decommits for same-type instance slot reuse

With the pooling instance allocator, we use virtual memory tricks to reset memories to their original size and discard their contents. For linear memories, both are important even when reusing the same memory for a fresh instance of the same type: the fresh instance mustn't observe stale contents, nor must it see a larger linear memory heap than expected.

For GC using instances, neither of these applies in the same way, so we could consider avoiding some of this work:
- with the copying collector, to avoid making stale contents observable all we need to do is reset the bump allocator's offset to the beginning.
- GC heaps don't have an observable upper bound the way linear memories do, since our use of wasm memories is an implementation detail to begin with.

What I'd propose is that we set the linear memory size for GC heaps to the configured maximum slot size right away (if we aren't already doing so; I didn't check that part) and skip decommitting for memories whose allocated size is < `pooling-memory-keep-resident`.

Note that AFAICT we're not applying instance type affinity to GC heap memories at all, so that'd have to change as well for this to be useful.

Start by tracing the pooling instance allocator and its GC heap handling, including the copying collector, configured maximum slot size, and pooling-memory-keep-resident setting. Check how instance type affinity is applied to GC heap memories; done means same-type reuse resets observable state without unnecessary decommits while preserving the proposed sizing behavior.

Written by the indexing model from the issue text.