Decouple source network deadlines from FFmpeg pipe backpressure

[jcll]

Problem

The streamed-source range request keeps its network timeout context active while up to 8 MiB is copied into the FFmpeg pipe. FFmpeg runs with real-time pacing (-re), so a valid low-bitrate range or temporarily stalled consumer can take longer than the source request timeout to drain even though Plex responded completely and on time. The range is then canceled and FFmpeg receives truncated input.

Affected code:

• internal/sourcestream/source.go (range request and pipe copy)
• internal/sourcegateway/ (bounded range capability contract)
• internal/packager/ (real-time FFmpeg consumer)

Why this is deferred

It requires an unusually slow consumer or low-bitrate/stalled stream, but the current deadline combines two unrelated failure domains and can reject valid media.

Proposed scope

• Read and validate each already-bounded source range into an application-owned buffer while the network deadline is active.
• Close the HTTP response and release the network context once the complete range is present.
• Feed the validated buffer to the pipe under the preparation job context, so cancellation still interrupts a blocked consumer.
• Keep memory strictly bounded by the configured maximum range size; do not introduce unbounded read-ahead.

Acceptance criteria

• A fast upstream response followed by a pipe stall longer than the network timeout still delivers the complete range when the job remains active.
• A genuinely slow or incomplete upstream response still fails at the network deadline.
• Canceling the preparation interrupts both network reads and blocked pipe writes.
• Range length, Content-Range, capability, and maximum-byte validation remain fail-closed.
• Tests prove that network time and consumer backpressure are governed by separate contexts without goroutine leaks.