Adaptive eviction thresholds must use the same cost baseline as the path they guard

Review pattern: a warm pool admitted uncertain items on probation and evicted them if a call took more than max(250 ms, 3x the COLD per-call floor). Warm calls skip that floor entirely (warm good items ~68 ms), and a bad item added only ~50-60 ms per call, so the threshold (336 ms on a mid-size input, ~2 s on a large one) never fired. The bad items slowed every co-batched good item 2.4-2.8x for the whole session and were themselves slower warm than cold. The unit test passed only because its stub made a bad item cost 10x the real penalty. Lessons: compare against the guarded path's own recent baseline (p50 of calls without probationary items) or the item's own cold time; calibrate stub costs from real measurements; measure good items' latency with separate concurrent requests, not the batch total.