Audit follow-up: TarGzipBundleOutput leaks FileInputStream per binary asset

Parent epic: #36004

Finding

TarGzipBundleOutput.innerCopyFile uses IOUtils.copy(new FileInputStream(source), tar) without closing the input stream. The finally block closes the archive entry, not the source stream.

Report reference: dotCMS/src/main/java/com/dotcms/publishing/output/TarGzipBundleOutput.java:98

Potential impact

Large or sustained bundle generation / push publishing may leak file descriptors until publishing fails with Too many open files or broader node I/O issues.

Suggested validation

Run bundle generation with many binary assets and observe open file descriptor growth around this code path.

Possible fix

Use try-with-resources, for example try (InputStream in = Files.newInputStream(source.toPath())) { IOUtils.copy(in, tar); }.

Caveat

This was AI-found by Claude from .scratch/audit/REPORT.md. Please perform secondary validation of correctness, severity, and value before actioning.

Start at dotCMS/src/main/java/com/dotcms/publishing/output/TarGzipBundleOutput.java:98 and inspect innerCopyFile, focusing on the source stream and archive-entry cleanup. Run bundle generation with many binary assets while observing open file descriptor growth around this path. Done means the source stream is reliably closed and the validation no longer shows descriptor growth.