Prevent hang when output is requested after Stream input has finished

[Jaybhade]

Every Stream-based input path waits for the Writable side to emit finish before flattening the accumulated chunks. finish is emitted only once, so any listener registered after it has already fired never runs — the Promise never settles and the callback is never called, with no error and no timeout.

const pipeline = sharp().resize(320, 240);
createReadStream(input).pipe(pipeline);
await once(pipeline, 'finish');   // or await pipelineAsync(readable, pipeline)

await pipeline.toBuffer();        // hangs forever

Measured against main, waiting 2s for each call on an instance whose Writable side has already finished:

call	before	after
toBuffer()	hangs	resolves
toBuffer(callback)	hangs	resolves
toFile(path)	hangs	resolves
metadata()	resolves	resolves
metadata(callback)	hangs	resolves
stats()	hangs	resolves
stats(callback)	hangs	resolves
clone() then output	hangs	resolves
.pipe(writable)	resolves	resolves

The two that already worked each carry their own workaround for this, added one entry point at a time: metadata() checks writableFinished (df97120, #3451) and Stream output re-emits finish when streamInFinished is set (d8df503, #671). Everything else was left waiting on an event that had gone.

Fix

Both ad-hoc guards are replaced with a single _whenStreamInFinished helper, used everywhere the input stream is awaited:

function _whenStreamInFinished (fn) {
  if (this.writableFinished) {
    fn();
  } else {
    this.once('finish', fn);
  }
}

Calling the handler directly means Stream output no longer has to re-emit finish, which also stops that event being delivered twice to any listener the caller has attached. With nothing left reading streamInFinished, its bookkeeping in _write goes too — and with it the finish listener that was attached to every Stream-fed instance.

An input stream that finishes without producing any data now rejects with the usual unsupported-format error rather than hanging, since writableFinished does not depend on a chunk having arrived.

No public API or type definitions change.

Tests

Eight cases in test/unit/io.js, one per entry point above, each requesting output only after finish has been awaited. Seven of them hang on main and are only reported as failures by the 60s suite timeout; the eighth (metadata() via Promise) passes both before and after, and is included so the path that had the original workaround stays covered.

npm test is otherwise unchanged: 1821 tests, 100% branch coverage retained.

[lovell]

This looks like a neat solution, thank you very much.