Inline `dec_ref`, `trace_gc_ref`, and `dealloc` into
`dec_ref_and_maybe_dealloc`'s main loop so that we read the `VMDrcHeader` once
per object to get `ref_count`, type index, and `object_size`, avoiding 3
separate GC heap accesses and bounds checks per freed object.

For struct tracing, read gc_ref fields directly from the heap slice at known
offsets instead of going through gc_object_data → object_range → object_size
which would re-read the object_size from the header.

301,333,979,721 -> 291,038,676,119 instructions (~3.4% improvement)

…exists

When the GC store is already initialized and the allocation succeeds, avoid
async machinery entirely. This avoids the overhead of taking/restoring fiber
async state pointers on every allocation.

291,038,676,119 -> 230,503,364,489 instructions (~20.8% improvement)

Avoids converting `ModuleInternedTypeIndex` to `VMSharedTypeIndex` in host code,
which requires look ups in the instance's module's `TypeCollection`. We already
have helpers to do this conversion inline in JIT code.

230,503,364,489 -> 216,937,168,529 instructions (~5.9% improvement)

This reverts commit 41dcbd931170c0e510b5baf9e0cafa19a83c0ddd.

`Layout::from_size_align` rejects sizes greater than `isize::MAX`, causing
`add_capacity` to silently discard new capacity blocks that exceed this
limit. This meant the free list could not grow beyond ~2 GB on 32-bit even
though our `u32` indices can address up to ~4 GB.

Fix by calling `dealloc_impl` directly in add_capacity, bypassing the `Layout`
construction. The block index and size are already properly aligned u32 values,
so the `Layout` validation is unnecessary for internal free list bookkeeping.

Also remove a redundant `debug_assert` in `dealloc_impl` that constructed a
`Layout` (hitting the same `isize::MAX` limitation), since the alignment
invariant is already checked by the adjacent assertions.