feat(youtube): SABR extractor support

[Priveetee]

First real integration of the SABR extractor (supersedes the PoC #68). Pairs with the client SABR PR (coming) and the media3 migration InfinityLoop1308/PipePipeClient#45. Tracking: #42.

Docs (how SABR works end to end): https://priveetee.github.io/Docs-PipePipe/developer-guide/introduction

Related:

• feat(player): migrate from ExoPlayer 2.18.7 to media3 1.4.1 PipePipeClient#45 (media3, the client SABR builds on it)
• [YouTube] Content Not Yet Suppoted (SABR) after 5.1.0 PipePipe#2330 ([YouTube] Content Not Yet Supported (SABR) after 5.1.0)
• [YouTube] Coordinating efforts on SABR implementation TeamNewPipe/NewPipe#12248 (coordinating SABR)

Summary

Adds the YouTube SABR (Server ABR) extraction path end to end: UMP wire reading, the proto request/response codecs, the typed UMP parts (media, policy, context, onesie...), response decoding + mp4/webm segment index parsing, and the session/state model the client pump drives. A new DeliveryMethod.SABR exposes it.

Changes

• DeliveryMethod.SABR delivery method.
• UMP reader + proto codec, response decoder, typed parts (media/policy/context/onesie/misc).
• media segment + mp4/webm index parsers, request builder + client profile, info/formats/probe + PO token provider interface.
• session, state and hardware-aware format selection; SABR wired into YoutubeStreamExtractor.
• reader-driven contiguous buffered-range reporting + play-head-aware byte-bounded eviction + reload budget.
• SabrLiveMetadata getters (live foundation).
• YoutubeParsingHelper: Safari player request now uses the live web client version (the hardcoded one started returning page needs to be reloaded).

Why

YouTube serves some videos SABR-only; the old paths return "Content Not Yet Supported". This adds a real extractor path, with the client PR as the runnable counterpart.

Impact / Compatibility

The new sabr/ package and DeliveryMethod.SABR are additive. The one behavioural change is in YoutubeStreamExtractor: a FORCE_SABR_FOR_TESTING flag (currently true) routes every YouTube video through the SABR pipeline, so HLS/DASH/progressive are bypassed on purpose to stress-test SABR on everything. With the flag false (production default), HLS/DASH stay untouched and SABR only fills the SABR-only / no-HLS gap that upstream currently throws ContentNotSupportedException on. The Safari client-version fix also helps the existing logged-in path.

Validation

• ./gradlew :extractor:compileJava -x checkstyleMain
• Exercised end to end via the client on Pixel 8 and emulator (probe -> session -> segments -> playback).

Notes

• First real integration, not a PoC, but still WIP, residuals tracked in the client PR.
• Right now FORCE_SABR_FOR_TESTING = true on purpose: all YouTube playback goes through SABR with no HLS fallback, so we exercise the SABR path on every video. It flips back to false before merge (then HLS stays as fallback and SABR only covers the SABR-only gap).
• Not ready to merge yet, more testing coming.
• checkstyleMain excluded, fails repo-wide unrelated to this change.

[Priveetee]

bit of context since this isn't a fresh idea: the PoC #68 (and the client PoC InfinityLoop1308/PipePipeClient#43) were exactly that, throwaway PoCs to prove SABR actually plays end to end. they did their job, so i closed #68 rather than keep pushing onto a messy branch.

this is the real integration, rebuilt clean. the SABR extractor stands on its own here, and i reworked the buffering to be reader-driven (pacing + cache eviction follow what the player has actually read, not the play head, so it doesn't deadlock or blow up memory anymore), plus the Safari client-version fix and the live-metadata foundation. on the client side i split it too: the media3 migration is its own PR (InfinityLoop1308/PipePipeClient#45) and the SABR client sits on top.

still WIP, not for merge yet (FORCE_SABR_FOR_TESTING is on so every video goes through SABR while i hammer it), but this is where it continues from now :)