[christopherklint97]

Cause

Recent physical-iPhone client timestamps: NFL REPLAY INFO HD 40.054s to loadeddata / 43.841s to playing with three play calls; ESPN 17.595s to playing. Those logs are not a decoded-frame inventory or exhaustive trace of the user's reported 1–2 minutes. The previous native selection first attempted strict primary authorization/startup, then compatibility, adding a redundant authorization budget (up to 50s) or first-frame watchdog cycle. A separate fresh compatible NFL request served first TS bytes in 2.39s.

Fix

• Native Apple/WebKit directly authorizes signed compatibility HLS from first play, reconnect, explicit retry, and remount. No speculative parallel primary provider connection.
• Desktop/MSE and AVPlay retain primary delivery; finite/audio exclusions unchanged.
• Remove obsolete primary-failure tracking and sequential fallback. Preserve total 50-second hard abort including response-body parsing, terminal 401/403, native no-TS, bounded no-progress watchdog, healthy recovery, and backend/channel/generation guards.
• Add fixed channel/delivery/elapsed-ms authorization and first advancing-media diagnostics; no provider URLs, tickets, tokens or credentials.

Verified

• Observed RED→GREEN. Full frontend 389 passed / 50 files; typecheck, ESLint, build, diff checks passed. Independent review passed with two nonblocking coverage suggestions.
• Actual-app cold isolated compatible buffer: Apple-UA Chromium first authorization went directly to /api/live-compatible, ZERO primary requests. Authorization diagnostic 9419ms, first segment HTTP200 at12500ms, loadeddata at12624ms. This is routing/delivery evidence, NOT physical WebKit/iPhone decoder acceptance; sampled frame count was0.
• Existing backend/strict seam/limits/archive runtime code unchanged; documentation updated to reflect native-first selection.

Release

CI37512031303 passed packaged server/Python tests, frontend checks and ARM64 build; squash merged to mainf91e9706e6855da74a4eb686777cd60f7be0891a, same treeb7e551e93d0214e952d773389a58b5fc61548dcd as reviewed/tested source8ad554b40fd482fb3c364ddab92edaf4c4d2fb77.

Deployment uses a newly built ARM64 image with the tested frontend asset tree over the existing CI-verified runtime baseef2475ce575d1a96679c000d133c6b2865f5342ef4dc84d5cc0eaf8633a43767. Git diff explicitly proves server/src, server configuration/dependencies, root dependency manifests, Dockerfile and Compose unchanged before reusing the runtime. This is a local frontend-overlay image, NOT a claim of downloading the new full CI image. New image804d5644fa372fb070feaf6cc06394dd37a6db1fccb1bffe0a7a0ba675b03912, PyAV14.2.0/worker/stitch imports passed, Compose full force-recreation returnedexit0. Production readback passed: health200 and served HTML/service-worker/entry bundle bytes match both running image and tested build; durable channel count unchanged238534. Actual deployed app Apple-UA routing test FIRSTauthorizescompatible and makes ZEROprimaryrequests; authorization diagnostic7293ms, firstsegmentHTTP20015199ms from the Playwright click procedure (which includes action wait), loadeddata15700ms with sampledframes0. This is native-route/delivery verification, NOT physical-WebKit/iPhone first-frame timing. Two production1080pH264/AAC HLSsegments also passed strict FFmpeg decode.

Retain cold-boot caveat: initial post-restart health probe failed its720-second deadline; a later probe returnedhealth200. Logs show server listening before a long gap and then a batch of queued health requests; exact synchronous startup phase is not established here. The later0.196-second warm probe is NOT boot-time evidence. Slow service boot is separate from the removed client primary-first cycle. Physical iPhone startup timing must be retested; do not claim HTTP delivery timing is device first-frame timing.