Race condition in evaluating post-processing timestamp

[cmccambridge]

When an output file is moved or deleted quickly after processing completes, especially in parallel processing of many files, OcrTask may not yet have been scheduled to sanity check the final timestamp and activate on-success actions such as deleting or archiving the input file before the output is no longer accessible, causing output_mtime measurement to fail.

Should either remove the timestamp sanity check and rely on the return code from ocrmypdf or find a way to win this race, e.g. moving to the final path from /ocrtemp as a final step.