Resource leaks and bitmap copy bug in image processing

[guiyanakuang]

Description

Code review (Session 16) found resource leaks and a bitmap copy bug in the image processing layer:

M1: WebpImageWriter — FileImageOutputStream and ImageWriter not closed

File: WebpImageWriter.kt:27-43

writeImage creates a FileImageOutputStream and an ImageWriter, but neither is closed after writing. Both hold native file handles. If writer.write() throws, the FileImageOutputStream is leaked. On Windows, this prevents the file from being moved/deleted until GC collects the stream.

M2: DesktopThumbnailLoader.readOriginMeta — InputStream not closed

File: DesktopThumbnailLoader.kt:36

readOriginMeta creates a buffered input stream that is never closed. Properties.load() does not close the stream.

M3: DesktopThumbnailLoader.defaultSave — OutputStream not closed

File: DesktopThumbnailLoader.kt:128

defaultSave creates a buffered output stream for storing metadata but never closes it. Properties.store() does not close the underlying stream.

M4: MacCropTransformation — fallback pixel copy doesn't copy pixels

File: MacCropTransformation.kt:43-47

The fallback path when extractSubset fails calls input.readPixels(srcX, srcY) but discards the return value. The copy bitmap is returned with zeroed pixels (transparent/black). Should use readPixels + installPixels to actually copy pixel data.

m4: DesktopIconColorExtractor — plain MutableMap not thread-safe

File: DesktopIconColorExtractor.kt:27

colorCache is a plain mutableMapOf() (LinkedHashMap), but access is guarded by StripedMutex with 32 stripes. Two different source keys on different stripes can concurrently read/write the LinkedHashMap, risking ConcurrentModificationException or data corruption. Should use ConcurrentHashMap.