LR-BEHAV-BG-TASKS: a render job that panics fails instead of never answering

A panic inside RenderJob::run or QuickJob::run (a raw decoder or pipeline bug) unwound the
job pool's worker without sending a result. The slot stayed pending and its key was never
asked for again, so the loupe or the thumbnail rendered forever; and the pool never
replaces a dead worker, so after as many such panics as it has workers (2–6) no photo
rendered until LightCraft was restarted.

Both now catch the panic (guard::catch) and return it as the job's failure, answering the
request it came from, so the renderer records it like any failed render: no retry until
the catalog changes, and the workers live on. run() is the one place every render goes
through (the pool, export, Build Previews, contact sheets, face and AI-mask workers);
callers that had their own guard keep working, and the watermark preview's, now
redundant, is gone. The web build aborts on panic, so nothing changes there.

Co-Authored-By: Claude <noreply@anthropic.com>

docs/whats-new.md

@@ -45,6 +45,10 @@
 - Upgrading from a Windows installer older than 0.6 (such as 0.5.0) keeps LightCraft in the folder it was installed
   in, instead of moving it back to Program Files (issue #399). If that folder has been deleted since, the upgrade
   installs to Program Files.
+- A photo that runs into a bug in LightCraft while it renders (in a raw decoder or the editing pipeline) now fails
+  like a photo that can't be opened, with the reason, instead of rendering forever; its thumbnail stops waiting too.
+  Each such bug used to take one of the render threads with it, so after a few of them no photo rendered until
+  LightCraft was restarted. The bug is still written to the log (Help ▸ Open Log Folder) for a report.
 
 ## 2026-10-10