stream2: flush extant data on read of ended stream

A ReadableStream with a base64 StringDecoder backed by only
one or two bytes would fail to output its partial data before
ending. This fix adds a check to see if the `read` was triggered
by an internal `flow`, and if so, empties any remaining data.
    
Fixes #7914.
I see that it is way more restrictive here right now, this is good, but a bit non-obvious to me... Why should this be applied only when the `state.decoder` is present? Could this condition happen without decoder?

What if this condition happens when stream is non-flowing, what behavior will we see?