thumbnail: bound the decode thread pool so large folders don't peg the CPU

thumbnail_get_async used g_task_run_in_thread, which runs on GLib's
unlimited shared thread pool — every visible cell's thumbnail decode
spawned its own thread, pegging every core (load ~20, 74 running
threads on a 613-image folder). Move the decode onto a GThreadPool
owned by Thumbnail, capped at max(1, min(num_cpus/2, 4)) threads.
g_task_return_* still marshals each result to the main thread, so
callbacks are unchanged. Observed: 74 -> 2 active decode threads,
load ~20 -> ~5.

If the pool failed to create, fall back to g_task_run_in_thread so
thumbnails still work (just unbounded) rather than not at all.

0 files changed, 0 insertions, 0 deletions