[naruto-lgtm]

Repro: write a POIFS with a 10,000-byte stream, reopen it, delete the stream (or replace it with 10 bytes through createOrUpdateDocument) and call writeFilesystem(OutputStream): every byte of the old stream is still in the output. The in-place path behaves the same, e.g. opening an .xls read-write, removeSheetAt and HSSFWorkbook.write() leaves all cell records of the removed sheet in the file.
Cause: POIFSStream.free only sets the FAT/SBAT entries to unused and leaves the block contents, while writeFilesystem() and writeFilesystem(OutputStream) write the whole data source, free blocks included (CWE-226). Every path that gives up stream space goes through it: DirectoryEntry.delete, POIFSDocument.replaceContents (behind createOrUpdateDocument, the HPSF property writers and the in-place write() of HSSF, HSLF and HWPF) and DocumentOutputStream.
Fix: zero each big or mini block in free() before marking it unused, the same state POIFS gives newly allocated blocks.

HSSFWorkbook.write(OutputStream) and write(File) build a new file system and were never affected; in-place saves and direct POIFS edits are. The cost is one extra write per released block, the same order as writing the replacement data. File systems that aren't modified are still written byte for byte as before, verified against a few Office-written samples. Blocks that aren't backed by data (a truncated file) are skipped, so deleting entries of such files keeps working.

One related leftover is out of scope here: when the directory shrinks, the 128-byte entry of a deleted stream (its name, not its data) can stay in the unused tail of the last directory sector. Clearing that tail also rewrote the free directory entries of unmodified Office files, so I left it for a separate change if you want it.

TestPOIFSStream.deletedDataIsNotWrittenOut deletes a big-block and a mini-stream entry and shrinks a third, through writeFilesystem(OutputStream) and in place, and fails before the change. :poi, :poi-scratchpad, :poi-ooxml and :poi-integration pass locally apart from TestDateSerialRange.testEdgesOfTheRange and three SXSSF/XSSF auto-size width tests, which fail the same way on trunk here.