GC: grow-vs-collect heuristic (#12942) regresses allocation-heavy throughput ~2x — suggest reverting

Upgrading [Wado](https://github.com/wado-lang/wado) from wasmtime 44 to 45 (default `drc` collector) made our GC-heavy benchmarks ~2x slower. I bisected it to #12942.

| workload (drc, -O2) | 44 | 45 | ratio |
|-|-|-|-|
| json/canada | 112 ms | 229 ms | 2.04 |
| sqlite_parse | 618 ms | 1380 ms | 2.23 |
| syntax_highlight | 971 ms | 1962 ms | 2.02 |

Pure-compute workloads (count_prime, mandelbrot, sieve) are unaffected.

The heuristic decides collect-vs-grow purely on `live < capacity/2`, with no notion of allocation rate. For high-allocation / small-live workloads the live set stays small, so a collection always frees enough and the heap never grows past its initial size — it collects on every heap-fill (GC thrashing). This is, ironically, close to the "lots of temporary garbage" case the PR cites as motivation. `Collector::Null` runs json/canada in ~15 ms vs ~148 ms for drc, so the cost is collection; `gc_heap_reservation` (even 1 GiB) has no effect.

I'd suggest reverting it for now: the grow-to-the-limit behavior in 44 was a reasonable default (memory is still bounded by the GC heap size limit), and the new heuristic regresses a common workload class.

Then, before re-landing a heuristic, it might help to add a GC throughput benchmark to wasmtime's CI so this kind of regression is caught up front. Here is a self-contained reproducer (a Wado-compiled `wasi:cli/command` component that allocates many short-lived GC objects) that could serve as a reference: https://gist.github.com/gfx/133a82db2817c160da6cbc221b0a4329 — on it, wasmtime 44 ≈ 1005 ms vs 45 ≈ 1950 ms.