High GC overhead in JIT workload

### Summary

Hi Codon maintainers,

We noticed a performance degradation in a JIT/Python interop workload that appears to be correlated with native GC marking. Codon currently uses the Boehm GC, which is a conservative GC that identifies unreachable objects by tracing pointer chains. Since it cannot precisely distinguish object pointers from pointer-like values, GC collection can become expensive in JIT scenarios where many thread stack frames need to be scanned and marked during `GC_collect_or_expand`.

### Attached traces

I am attaching two Chrome trace JSON files:

- [codon_gc_regression_case_1.trace.json](https://github.com/user-attachments/files/31210931/codon_gc_regression_case_1.trace.json)
- [codon_gc_regression_case_2.trace.json](https://github.com/user-attachments/files/31210944/codon_gc_regression_case_2.trace.json)

They can be opened with Chrome's trace viewer / Perfetto UI.

### Question

- Is this level of GC marking overhead expected for JIT workloads under the current Boehm GC integration?
- Are there recommended ways to reduce this overhead, especially for workloads that create many temporary Codon/Python interop objects or views?

I can try to provide a smaller reproducer if that would be helpful. For now, the attached traces preserve the relevant runtime behavior while removing application-specific details.

Thanks!

Open codon_gc_regression_case_1.trace.json and codon_gc_regression_case_2.trace.json in Chrome's trace viewer or Perfetto, then inspect the Boehm GC marking path around GC_collect_or_expand. Compare the traces to determine whether marking causes the reported JIT/Python interop overhead. Done means establishing whether the behavior is expected and documenting a supported way to reduce it, or identifying the information needed for a smaller reproducer.

Written by the indexing model from the issue text.