Premature resource finalization in `Stream.bracket`

Version: co.fs2::fs2-core::3.10.2

When running the code https://scastie.scala-lang.org/btTjBsN3QWGSP8S0AMPz6A, the Stream.bracket resource closes unexpectedly before the inner process and emit streams complete their operations.
It seems that somehow the Stream.bracket sticks to the incoming stream argument in the processData function.

The lines .chunkN(1).unchunks are needed only to simplify the code, which is more like this https://scastie.scala-lang.org/pFqksNB6TIeVl9emDlInjA

  val input = Stream
    .force {
      Queue
        .unbounded[IO, Option[Int]]
        .flatTap { q =>
          Vector(3, 1, 2, 3).map(Some.apply).traverse(q.offer) *> q.offer(None)
        }
        // .map(q => Stream.fromQueueNoneTerminated(q, 1)) // [1] works
        .map(q => Stream.repeatEval(q.take).unNoneTerminate) // [2] doesn't
    }
    .evalTap(x => IO.println(s"> $x"))

In the actual code, line [2] is used inside a third-party library.

Output:

> 3
=== START PROCESS === with 3 elems
> 1
> 2
>>> Got Chunk(1, 2)
> 3
=== END PROCESS ===
>>> Got Chunk(3)
< Emitting element #0
< Emitting element #1
< Emitting element #2
Vector(element #0, element #1, element #2)

Expected output:

> 3
=== START PROCESS === with 3 elems
> 1
> 2
>>> Got Chunk(1, 2)
> 3
>>> Got Chunk(3)
< Emitting element #0
< Emitting element #1
< Emitting element #2
=== END PROCESS ===
Vector(element #0, element #1, element #2)

Start by running the linked Scastie reproduction and compare Stream.bracket behavior with the two queue stream constructions shown in the issue. Trace how the incoming stream is used by processData and how the process and emit streams complete. Done means the resource remains open until both inner streams finish and the output matches the expected ordering.