Fix asynchronous thumbnail generation race

[LostOne1000]

Priority

High

Summary

exportThumbnail() treats photo:requestJpegThumbnail() as though thumbnail generation completes synchronously. The function can return the temporary file path before the callback has written the JPEG.

This creates a timing-dependent race that may be hidden when Lightroom already has a cached preview but can fail with uncached previews, newly edited photos, slower storage, or larger catalogs.

Relevant code

lightroom-llama.lrplugin/LrLlama.lua

Current flow:

local success, result = photo:requestJpegThumbnail(
    512,
    512,
    function(jpegData)
        -- JPEG is written here
    end
)

if success then
    return tempPath
end

The returned request status does not guarantee that the callback has completed or that tempPath exists.

Expected behavior

Code that displays or encodes the thumbnail must execute only after Lightroom has supplied the JPEG data.

Implementation notes

Refactor thumbnail acquisition so that completion is explicitly callback-driven.

Potential approaches:

• Pass a completion callback into the thumbnail service.
• Retain the thumbnail request object until the callback completes.
• Store the JPEG only after confirming that valid data was returned.
• Continue dialog setup or image encoding from the completion callback.
• Return structured errors rather than an unverified path.

Avoid polling for the file unless Lightroom SDK limitations make a callback-driven flow impractical.

Acceptance criteria

• The thumbnail path is never used before the JPEG has been completely written.
• The Lightroom thumbnail request remains referenced until completion.
• Missing or invalid thumbnail data produces a recoverable user-facing error.
• Opening the dialog with an uncached image does not intermittently show a missing preview.
• Generating metadata cannot attempt to encode a nonexistent thumbnail.
• Behavior is tested with cached and uncached Lightroom previews.