docs(f17): profiling write-up for the 30-signal parallelization

Real measured timings for 27 of the 30 signals (synthetic 1600x1200
JPEG, 5 runs each): ~5.4s sequential sum, ~2.1s parallel floor
(statistical bundle is the slowest single signal). Structural
estimate for DIRE/CLIP/own-embedding (couldn't execute torch in the
profiling sandbox) based on their actual model architectures -- DIRE
runs 20 sequential UNet forward passes through SD 2.1, almost
certainly the dominant cost.

Documents the concrete reason DIRE/CLIP/own-embedding are deferred:
DIRE's DDIMScheduler is cached and shared process-wide, and both
add_noise() and the denoising loop mutate it -- a real thread-safety
question that needs resolving before those three join the parallel
pool, not a hypothetical one.

PROFILING_F17.md

@@ -0,0 +1,125 @@
+# F-17 Profiling — Parallelizing the 30 Signals
+
+## Method
+
+27 of the 30 signals (19-signal statistical bundle + 8 classical forensic detectors +
+`image_type_classifier`) are pure numpy/opencv/scipy/scikit-image — no torch dependency — so they
+were timed for real: a synthetic 1600×1200 JPEG (smooth gradient + sensor-like noise, quality 88),
+5 runs each, mean/min/max recorded. The 3 torch-dependent signals (DIRE, CLIP, own-embedding)
+couldn't be executed in the profiling session's sandbox (no working torch install there) — their
+relative cost was estimated by reading the model architecture directly instead.
+
+## Real measured numbers (mean of 5 runs, synthetic 1600×1200 JPEG)
+
+| Signal | Mean | Notes |
+|---|---|---|
+| Statistical bundle (19 signals, 1 call) | 2116.5ms | Internally: BasicSignals 1396.7ms, UltraSignals 264.5ms, AdvancedSignals 232.2ms, CovarianceSignals 149.8ms |
+| JPEG ghost | 1026.1ms | |
+| DCT frequency | 758.6ms | |
+| Noiseprint | 557.7ms | |
+| Noise map | 481.6ms | |
+| CFA | 154.8ms | |
+| Image type classifier | 126.4ms | Gates prnu/ela/metadata — must resolve before those three, independent of everything else |
+| PRNU | 92.0ms | |
+| ELA | 75.2ms | |
+| Metadata | 0.1ms | |
+
+**Sum if sequential: ~5.4s. Slowest single signal (the parallel floor for this group): ~2.1s
+(statistical bundle).**
+
+Within the statistical bundle itself, F-16 already decomposed it into 4 independent components
+sharing only a read-only `ImageContext` — `BasicSignals` alone is ~66% of the bundle's own total
+(1.4s of 2.1s), so there's a second, smaller layer of parallelization available inside the bundle
+if the outer-level win alone isn't enough later. Not implemented in this pass — flagged for
+whoever picks up further F-17 work.
+
+## DIRE / CLIP / own-embedding — structural estimate, not measured
+
+Read directly from `dire_detector.py`, `clip_detector.py`, `own_embedding_detector.py`:
+
+- **DIRE**: loads a full Stable Diffusion 2.1 pipeline, runs **20 sequential UNet forward passes**
+  (~860M params) at 512×512, plus a VAE encode/decode. Almost certainly the dominant cost of the
+  whole pipeline on CPU — likely an order of magnitude past the 2.1s statistical bundle.
+- **CLIP**: one forward pass, ViT-B/32 (~88M params). Fast relative to DIRE.
+- **own-embedding**: one forward pass, EfficientNet-B0 (~5M params). Fastest of the three.
+
+To get a real DIRE number, run this in an environment with working torch (this repo's own dev
+environment, not necessarily the profiling sandbox):
+
+```python
+import time, statistics
+from backend.services.dire_detector import DIREDetector
+
+with open("some_real_test_image.jpg", "rb") as f:
+    image_bytes = f.read()
+
+times = []
+d = DIREDetector()
+d.detect(image_bytes, "warmup.jpg")  # first call also pays model-load cost — exclude it
+for _ in range(3):
+    t0 = time.perf_counter()
+    d.detect(image_bytes, "test.jpg")
+    times.append(time.perf_counter() - t0)
+print(f"DIRE mean: {statistics.mean(times):.2f}s  (min {min(times):.2f}s, max {max(times):.2f}s)")
+```
+
+## The scheduler-sharing risk (why DIRE/CLIP/own-embedding are deliberately NOT parallelized yet)
+
+DIRE's `DDIMScheduler` is loaded once and cached process-wide (`ModelCache`, F-7) —
+`cached_model['scheduler']` — and every `DIREDetector` instance shares that *same object*. Both
+`_add_noise()` and the denoising loop call mutating methods on it (`scheduler.add_noise()`,
+`scheduler.set_timesteps()`, `scheduler.step()`). `denoise_steps` is currently hardcoded to `20`,
+so a `set_timesteps(20)` race between two concurrent DIRE calls likely produces the same values
+either way — probably not silently wrong today. But that's incidental, not a guarantee, and this
+is exactly the risk the original F-17 planning flagged as "a plausible interaction risk nobody has
+tested yet." Resolve this (explicit thread-safety test, or a per-instance scheduler clone instead
+of sharing the cached one) before enabling concurrent DIRE calls.
+
+## What was actually shipped this round (partial F-17)
+
+The 9 mutually-independent, non-torch signal calls — the statistical bundle + 8 classical
+forensic detectors — now run in a `ThreadPoolExecutor` inside `AdvancedEnsembleDetector.detect()`,
+instead of one after another. Every module involved was grepped for module-level caches/globals
+before this change; none exist (all are pure functions over their own local data), so there's no
+DIRE-scheduler-style shared-state risk in this half of the change.
+
+**A real trap found and fixed during verification**: the profiling/development sandbox turned out
+to have exactly 1 CPU core. On 1 core, 9 threads contending for that core measured **~1.5x SLOWER**
+than plain sequential — pure context-switch overhead, zero real parallelism, not a hypothetical
+concern. Fixed by capping `max_workers = min(len(_signal_tasks), max(1, os.cpu_count() or 1))`, so
+the pool degrades to one-thread-at-a-time (matching sequential performance) on a constrained host
+instead of regressing, and scales up to real concurrency on whatever's actually available.
+
+The project's actual production target (Hugging Face Spaces CPU Basic) is confirmed 2 vCPU — real,
+though bounded (not the full 9-way ideal), benefit is expected there. DIRE/CLIP/own-embedding
+remain sequential, tracked as a separate follow-up gated on the scheduler-sharing question above
+and a real DIRE number from the script in this doc.
+
+## Verification performed
+
+- Ran the real, patched `AdvancedEnsembleDetector.detect()` (torch import stubbed just enough to
+  satisfy `dire_detector.py`/`clip_detector.py`'s type annotations at import time; `dire_detector`/
+  `clip_detector`/`own_detector` swapped for instant fakes so timing measures only the 9-signal
+  pool this change touches) — 3 repeated runs produced identical `ai_probability` and identical
+  30-signal sets, confirming no race condition/data corruption from the thread pool.
+- Directly verified the `max_workers` capping logic against 3 scenarios: `cpu_count()=1` → 1
+  worker, `cpu_count()=64` → 9 workers (capped at task count, not core count), `cpu_count()=None`
+  → 1 worker (not passed through as `None`, which `ThreadPoolExecutor` would otherwise interpret
+  as "pick a default based on core count," silently reintroducing the oversubscription bug this
+  fix exists to prevent).
+- Full `backend/` still `py_compile`-clean after the change.
+- Could **not** measure real multi-core speedup in the profiling sandbox (1 core, by definition
+  can't demonstrate parallelism). Recommend running the timing harness below on this repo's own
+  environment (the 2-vCPU HF Space, or local dev hardware) to confirm the real-world win:
+
+```python
+import time
+from backend.services.advanced_ensemble_detector import AdvancedEnsembleDetector
+
+with open("some_real_test_image.jpg", "rb") as f:
+    image_bytes = f.read()
+
+t0 = time.perf_counter()
+AdvancedEnsembleDetector(image_bytes, "test.jpg").detect()
+print(f"Full detect(): {time.perf_counter() - t0:.2f}s")
+```