Background verification jobs cancelled by free/GC silently leave provisional state in force

Pattern seen reviewing a waveform-reader helper: an optimistic alias (serve signal A from stored signal B after sampled windows match) is accepted provisionally, then a background job compares full histories. The background job was an ordinary load job with no waiters, so a user free/cleanup call dropped it; the checker caught the cancellation error and ignored it, leaving the alias in the provisional (in-use) state forever -> wrong data served permanently for pairs that pass sampling but differ elsewhere. Lessons: (1) a verifier that awaits a cancellable job must treat cancellation as "no verdict" and revert to the safe path (or re-queue), never as success-by-default; (2) count the verifier as a waiter so GC does not drop it; (3) test with a deliberately wrong pair that passes the sample check, plus a free mid-verify. Related pitfall: learning a fixed per-call overhead as (measured - estimated work) from batched calls absorbs all estimate error into the overhead; learn it from single-item calls or the minimum, clamp it, and reset per input file.