Revert "perf(pools): size image/rayon pools to the CFS quota"

This reverts the image-pool migration (commit 5629ba6). The bench
(bench_pool_concurrency / POOL-CONCURRENCY.md) measured the one pool it could
isolate — the thumbnail decode semaphore — and found flat throughput, p99 AND
peak RSS (137 MiB) from K=1..16: shrink-on-load already makes each decode
RAM-cheap, so sizing it to the CFS quota gains nothing measurable. Adding code
without a measured benefit isn't worth it.

Kept: the effective_parallelism() helper (it has a *measured* win in the Tokio
runtime — benches/RUNTIME.md) and the benchmark itself (reusable). The ffmpeg
video fan-out has a plausible a-priori case (one OS process per permit) but is
left as a future, deliberately-measured change rather than shipped on
speculation. Doc updated to record the decision.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JG5yYZ9s868mJwqT2Qz7ez

src/common/di.rs

@@ -363,9 +363,9 @@ impl AppServiceFactory {
             if self.config.features.enable_video_thumbnails
                 && FfmpegVideoFrameService::is_available(&ffmpeg_path)
             {
-                // effective_parallelism respects the CFS quota (--cpus), not
-                // just affinity — so ffmpeg fan-out matches the real core budget.
-                let cpus = crate::common::runtime::effective_parallelism();
+                let cpus = std::thread::available_parallelism()
+                    .map(|n| n.get())
+                    .unwrap_or(4);
                 let concurrency = std::env::var("OXICLOUD_VIDEO_THUMBNAIL_CONCURRENCY")
                     .ok()
                     .and_then(|v| v.parse::<usize>().ok())