pipeline two /frame POSTs + HTTP keep-alive on the Scrypted side

Decouples network upload from firmware decode-and-paint. Before, the
inFlight boolean guard meant Scrypted sent frame N, waited for the
full ~80ms response (~40ms body upload + ~20ms decode + ~50µs paint +
ack), THEN sent frame N+1. The next ffmpeg frame arriving during that
window got dropped.

After:
- ScryptedViewportProvider keeps a per-host undici Agent with
  keepAliveTimeout 30s, connections:2, pipelining:0. Sockets stay
  open across /frame, /state, /config — saves the SYN+SYN-ACK+ACK
  round-trip every POST (small on LAN but real on Wi-Fi).
- Stream loop's inFlight boolean is now a counter capped at 2 so
  frame N+1 can begin uploading on socket B while frame N is still
  being decoded on the device via socket A. Roughly doubles effective
  throughput when body upload time dominates.

Firmware side:
- esp_http_server max_open_sockets bumped 7→4 explicitly: 2 for
  pipelined /frame + 2 spare for concurrent /state and /config slots.
  The JPEG decoder mutex still serialises decode (only one /frame
  can be decoding at a time); this change only unblocks the network
  half of the pipeline.

0 files changed, 0 insertions, 0 deletions