scrypted: per-fetch latency breakdown + p50/p95 windowed log

Replaces the single-sample "fetch #N: Xms" log with an aggregated
window every 10 fetches showing where the wall-clock budget actually
goes:

  fetch "kitchen" #10 (jpeg=147KB) wall p50=52ms p95=78ms |
      emit→post p50=0ms p95=14ms | req p50=51ms p95=76ms |
      body-read p50=0ms | inflight d0=4 d1=5 d2=1 | stale-drops=0

Buckets:
- emit→post: ffmpeg pushed JPEG to stdout → fetch() actually called.
  Nonzero = inFlight queue was full, frame waited.
- req: fetch() → Response headers (body upload + firmware ttfb +
  decode start + status line).
- body-read: Response → drained. Should be ~0 (empty body responses).
- wall: total of above three (matches the old single-sample number
  but with p95 visible).

Plus inflight depth histogram (d0/d1/d2 = how many other POSTs were
in flight when this frame queued) — d0 dominating means pipelining
isn't doing anything; d1/d2 mass means real overlap. stale-drops
counts X-Frame-Drop responses so we can see how often the firmware
rejected an out-of-order pipelined frame.

0 files changed, 0 insertions, 0 deletions