Follow-up to #13939: Auto-resolve a failed consume task when the same file is later consumed successfully

Description Follow-up to #13939. Problem When files arrive in the consume directory over a network share (SMB, written by a network scanner), a task occasionally fails with InputFileError because the file was read before it was completely written. The source file is not deleted on failure, so a later poll picks it up again and the second task succeeds, typically 1–3 minutes later. No data is lost. The failed task, however, stays in the "Needs attention" list indefinitely, even though the document exists. Users have to work out by hand, comparing timestamps and filenames, whether a failure is real or already resolved. Evidence (see #13939) The same filename failed at 14:28:39 and succeeded at 14:31:39 with no configuration change. Raising PAPERLESS_CONSUMER_STABILITY_DELAY to 60 s reduced the frequency but did not eliminate it. I can't say for certain that SMB client-side write buffering is the cause; the pattern is simply consistent with a partially wri…