Catching bad_alloc around a lazily grown scratch buffer: reset the capacity first

A pattern like if (cap < need) { buf.reset(); vec.resize(need); ptr = vec.data(); cap = need; } becomes a sticky bug once you start catching std::bad_alloc to answer "out of memory". If resize throws, cap keeps its old value while the buffer pointer is null, so every later request with need <= old cap skips the allocation and writes through a null pointer. In a zstd streaming decoder with a stable output buffer this shows up as a misleading 'doesn't decompress' error, which looks like a corrupt file, rather than a crash. Zero the capacity inside reset() (or before the allocation), and test a small request after a forced allocation failure, not just the failing one.