Unexpected Destination buffer is too small error when compressing small buffers with ZSTD_e_end and ZSTD_c_stableOutBuffer

[cghAndyReal]

Is your feature request related to a problem? Please describe.
Yes. When using ZSTD_compressStream2 to compress a single input buffer (with ZSTD_e_end enablingZSTD_c_stableOutBuffer parameter), I encountered the Destination buffer is too small error. This occurred even though my output buffer size was equal to the input buffer size (which should be smaller than ZSTD_compressBound(input_size) for small inputs). However, when I first call ZSTD_compressStream2 with ZSTD_e_continue (potentially requiring multiple calls for flushing) and then in ZSTD_e_end mode, the compressed output size is smaller than the input size. This suggests that the upfront buffer size check triggered by ZSTD_e_end + ZSTD_c_stableOutBuffer might be overly conservative for very small buffers where compression cannot be achieved.

Describe the solution you'd like
I'd like ZSTD_compressStream2 called directly with ZSTD_e_end (enabling ZSTD_c_stableOutBuffer ) to ​maintain the streaming behavior, incrementally writing data and only returning the dstSize_tooSmall error ​when the output buffer is truly exhausted during the compression process, not if the final compressed size could potentially exceed the buffer (as predicted by ZSTD_compressBound for very small inputs). Essentially, defer the dstSize_tooSmall check until compression actually runs out of output space, similar to how the multi-call (ZSTD_e_continue followed by ZSTD_e_end) approach works.

Describe alternatives you've considered

Additional context
My test string for above case is "test test test by test test in unit test. test test repetition."

[cghAndyReal]

Sorry, they seems to have same pattern, It is possible that compression needs more space for temporary use in ZSTD_c_stableOutBuffer case.

[Cyan4973]

Note: as mentioned, the output buffer size must be >= ZSTD_compressBound(inputSize) to guarantee success in one-shot compression scenarios. But it doesn't mean it refuses to work with less. It's just that it may fail during compression for lack of space, and the library provides no guarantee of success.

In normal mode, ZSTD_compressStream2() is immune to this requirement because it manages its own internal buffer, so it can guarantee that it will always behave correctly.
When ZSTD_c_stableOutBuffer is set, this internal buffer is no longer allocated (which is more or less the point). As a consequence, it totally relies on the provided output buffer. And yes, at several moments, there is a need for "some slack space". Nothing gigantic, but if one provides some small output buffer, this is more likely going to be an issue.

There are multiple places where size checks are made during compression. I wouldn't rule out that, in this scenario, one of these intermediate checks fires up. Which one exactly, is it legitimate, could it be tightened up safely, these are more difficult questions, which depend on the specific of the test, and require carefully analyzing traces. This sounds like a high effort, for what may in the end save a small quantity of bytes of slack space, or even none at all.