fix(backend): add the missing Life guard to PreviewProvider

[nocstah]

f8ecfbd gave FileOperations, SearchWorker and ThumbnailProvider a Life{mutex,alive} guard so a pool worker can never touch this after the owner is destroyed. PreviewProvider has the same pattern and wasn't in that commit — it still has no guard and no destructor.

Both of its async entry points hand a raw this to the global pool and then deliver with QMetaObject::invokeMethod(this, ...):

• requestText() — reads up to maxBytes and runs SyntaxHighlighter::highlight() on the worker, so the window is as wide as a large file's highlight pass
• requestAudio() — MediaInfo::extract() on the worker

invokeMethod() dereferences this to find its thread, so if the singleton dies while a worker is still in that read — app shutdown, or an xdg-desktop-portal picker answering and tearing the QML engine down — the worker reads freed memory.

Reproduction

Against f8ecfbd: 8 concurrent requestText() calls on a 560 KB highlightable file, provider destroyed mid-flight, freed block poisoned so a dangling read faults hard rather than silently reading stale-but-mapped memory.

3/3 runs SIGSEGV before, 0/3 after, at this frame (symbolized):

#0 QObject::thread()
#1 QMetaObject::invokeMethodImpl
#2 PreviewProvider::requestText(QString const&, int)::{lambda()#1}
#3 QRunnable::QGenericRunnable::Helper<...>::impl

AddressSanitizer is the better instrument here and is what you used for f8ecfbd; libasan wasn't available on my machine, hence the heap-poisoning harness. It reproduces the same frame I first saw in a real coredump — mine came from the FileChooser portal path (ThumbnailProvider, pre-f8ecfbd), which is what sent me looking at the sibling classes in the first place.

The change

Your own pattern from f8ecfbd, unchanged: Life{mutex,alive} in a shared_ptr that outlives the singleton, a destructor that marks it dead under the lock, and delivery that takes that same lock before touching this.

One deliberate difference from SearchWorker: the generation counters stay as plain members. They're only read inside the delivered lambda, on the object's own thread — unlike SearchWorker's directory walk, which polls its counter per entry from the worker and therefore genuinely needed the shared_ptr move.

Two files, +38/−2, no behaviour change on the happy path.