Initialization bug with helpers over `test`

This issue was copied over from: https://github.com/disneystreaming/weaver-test/issues/705
It was opened by: BalmungSan

I found a strange issue with weaver around initialization... or at least that is what I think.
It is a bit involved but hopefully, I can provide enough info for someone to take a look.

// First, we need a base Suite with a bunch of helpers:
trait FooBaseSuite extends IOSuite:
  override final val maxParallelism: Int = 1
  override final type Res = FooRes
  override final val sharedResource: Resource[IO, Res] = ???

  // Define helper method to reduce boilerplate:
  protected def fooTest(name: String)(check: Foo => Expectations): Unit =
    test(name) { foo =>
      IO(check(foo))
    }

// Then we need an object that extends such base Suite:
object FooSpec extends FooBaseSuite:
  // And use the helper method:
  fooTest(name = "Testing foo") { foo =>
    expect(...)
  }

The tests will fail because Foo is already closed (or so I think).

There are a couple of ways to fix the issue:

1. Don't have a trait + object but just a single object
2. Remove the fooTest helper and replicate the boilerplate in each test
3. Make FooSpec a class which accepts an (unused) GlobalRead

Things that didn't work:

• Using abstract class rather than trait
• Moving fooTest from the trait (FooBaseSuite) to the object (FooSpec)

More info:

• Scala 3.3.1
• weaver: 0.8.3
• cats-effect: 3.5.1
• sbt: 1.9.6
• Java: GraalVM CE 17.0.8
• OS: Mac 14.0

No source file or test is named; start by reproducing the FooBaseSuite/FooSpec example with Scala 3.3.1, weaver 0.8.3, and cats-effect 3.5.1. Trace IOSuite initialization and resource lifetime around helper-registered tests, then verify that Foo remains usable and add a regression test for the trait/object case.