Drop the .byteranges sidecar dependency end-to-end once DASH reads ranges from the MPD

[jonathaneoliver]

Context

Follow-up to the LL-DASH byte-range issue. Once go-live/pkg/dash can source fragment ranges from manifest_fragmented.mpd, nothing in the serving path needs the per-segment .byteranges JSON sidecars any more — the encoder emits fully self-describing playlist.m3u8 and manifest_fragmented.mpd.

Note: the current sample encode (insane_fpv_shots_hydrofoil_windsurfing_p200_h264_xs, 2026-08-07) still writes the sidecars. They are redundant, not yet absent. This issue is about removing our dependence on them so the encoder is free to stop.

Sites that still generate or assume sidecars

Location	What it does	Action
go-upload/internal/util/byteranges.go:22 GenerateByteranges	Shells out to python3 /sbin/parse_fmp4_fragments.py once per segment (10s timeout each)	Make it a no-op when the playlist already carries #EXT-X-PART / the MPD carries mediaRange
go-upload/internal/api/routes.go:630 + go-upload/cmd/server/main.go:67	POST /api/content/{content_name}/generate-byteranges	Keep the endpoint for legacy content; report "skipped — manifest already self-describing"
generate_abr/create_abr_ladder.sh:2684 (Phase 6)	Generates sidecars during the local ladder build	Gate behind a flag; default off for fmp4 output
go-live/pkg/parser/byterange.go:108 and go-live/pkg/parser/playlist.go:170	Sidecar fallback when no #EXT-X-PART found	Keep — this is the legacy-content path

Also worth fixing while in here

go-live/pkg/parser/byterange.go keys its result map inconsistently between its two branches:

• #EXT-X-PART branch (:69) keys by filepath.Base(uri)
• sidecar fallback (:127) keys by the raw playlist line

Callers look up by segment.URI (e.g. generator/ll_hls.go:188). These agree only while playlist lines are bare filenames — which is true for current content, so this is latent, not live. Worth collapsing to one keying rule rather than leaving the trap set.

Acceptance criteria

• A fresh upload of self-describing content does not invoke parse_fmp4_fragments.py at all, and reports why it was skipped.
• Serving that content produces byte-identical HLS and DASH manifests with the sidecars deleted vs present.
• Legacy sidecar-only content still serves correctly.
• byterange.go uses one map-key convention across both branches.

Blocked on the LL-DASH MPD-reader issue landing first.

[jonathaneoliver]

Sizing: points:3 · Effort: ~half a day to 1 day · Priority: P2 · Value: medium

• points:3 — mostly deletion and gating across four known sites, plus the map-key collapse in byterange.go. Low unknowns; the hard thinking lives in the blocking issue.
• P2 — pure cleanup. Nothing breaks if we leave the sidecars being generated and ignored; we just keep paying a per-segment python3 subprocess on every upload.
• value:medium — the win is upload speed and one less encoder/server coupling, not new capability. The latent map-key inconsistency is the quiet part worth banking while we're in the file.

Blocked on #986 — the sidecar fallback can't be de-prioritised until DASH can read ranges from the MPD.