[Flight] Abort the cache signal when debug objects are retained (#37342)

A debug channel with a readable side lets the client fetch debug objects
lazily. For example, React serializes each component's props into the
debug model and defers the part of an object tree that exceeds the
model's object limit. A deferred object stays retained, and its debug
chunk stays pending, until the client asks for it or the channel closes.
The render can therefore complete while such an object is still
outstanding.

When that happens, `flushCompletedChunks` closes the main stream, sets
the request status to `CLOSED`, and returns before it reaches the block
that releases the render's resources. Once the client closes the debug
channel and the retained objects drop, a later flush does reach that
block, but the cache controller is only aborted while the status is
below `ABORTING`, and `CLOSED` is above it. The signal is therefore
never aborted at all rather than merely released late, so anything that
waits on `cacheSignal()` to clean up resources waits for the lifetime of
the process.

This change moves the cache controller abort above the debug stream
bookkeeping. An empty pending chunk count already means the render is
complete, and debug chunks carry development-only instrumentation rather
than the render's output, so the cache signal can abort at that point no
matter what the debug stream is still doing. The path that writes debug
chunks on the main stream can now reach this code on several flushes,
which is safe because aborting an aborted controller does nothing a
second time.

The taint queue cleanup stays where it is. A tainted typed array,
`DataView` or blob is checked against the taint registry as its chunk is
written, and such a write can happen long after the render completes,
either because the client queried a deferred debug object or because a
blob's stream resolved late. Moving it up would let those writes through
unchecked, and it would fix nothing, because unlike the abort it never
sat behind the status guard.