fix: Do not block in ChainedProcessorManager.next().

[gianm]

Previously, a blocking Future wait ran inside next(), which could cause a processing thread to block while waiting for the next processor to be ready. This patch fixes it by moving resolution to a callback.

[FrankChen021]

🟡 Changes recommended

The change removes the blocking wait from the first phase and synchronizes the phase transition correctly. One cleanup race remains in the asynchronous rest phase: after the rest manager has been created, a pending rest.next() can resolve after close and return a processor that is no longer owned by the executor. That processor needs the same post-close cleanup handling as processors returned by the first phase.

Reviewed 2 of 2 changed files. This was a static review; no local build or test commands were run.

Severity	Findings
P0	0
P1	0
P2	1
P3	0
Total	1

---

This is an automated review by Codex GPT-5.6 Luna(Max)

After addressing the findings or replying to the comments, you can request another review from me to trigger a new automated review.

[FrankChen021]

[P2] Clean up rest processors that arrive after close

Once restFuture has already been resolved, close() cannot cancel it; a pending rest.next() can therefore still resolve with a ProcessorAndCallback after the manager is closed. nextFromRest() forwards that value without checking closed or cleaning up the returned FrameProcessor, unlike the first-phase callback above. During a failure or cancellation, RunAllFullyWidget can discard this late processor after its manager has been closed, leaving its channels or other resources uncleaned. Route rest.next() through the same post-close cleanup path (or otherwise cancel/track the in-flight future).