lance_video: GOP decode index + planned prefetch for video blobs

[AyushExel]

Rebased on main now that #297 is merged — single commit, builds on #297's ranged streaming reader (which remains the fallback path).

What

Adds three optional columns to the videos table — moov_range, gop_frame_idx, gop_byte_offset (tagged swm:video_index_version=1) — and teaches the existing lance_video format to use them end to end. Not a new format: no new tables, no changes to existing columns or blob bytes. Datasets without the columns fall back to #297's streaming path; old readers ignore the new columns.

Why

#297 stops downloading whole episode MP4s, but the decoder still discovers byte ranges by seeking, one round-trip at a time. With a GOP index the reader knows every byte range a DataLoader batch needs before decoding: it prefetches all episodes' ranges concurrently and decodes from memory. On high-latency links (cross-region object storage) this collapses the per-window round-trip chain into one parallel fetch wave. It is also the prerequisite for Dataset.read_blob_ranges (lance#7864) — which needs the ranges as arguments — where the thread-pool fetch can later be swapped for lance-side coalesced IO.

How

• mp4_index.py (new): pure-Python MP4 box parser → GOP-level index (stss/stsz/stsc/stco/co64). Needs only ranged reads: building an index from object storage costs ~2 MB per episode, not a re-download. Index weight is ~130–570 bytes per episode (measured on VPT Minecraft: 128-frame GOPs).
• Writer: parses the index at write time — the MP4 bytes are already in memory, zero extra IO. Appending to a pre-index videos table keeps that table's schema (no mismatch).
• Reader: loads index columns up front (KBs for tens of thousands of episodes); __getitems__ maps windows → covering GOP byte ranges, prefetches per-episode ranges concurrently (_SparseBlobIO), then decodes. Unplanned reads fall through to ranged fetches, so correctness never depends on plan completeness.

Validation

• Sparse decode from planned ranges only (64 KB head + moov + one GOP ≈ 3.7 MB of a 173 MB VPT episode) is bit-identical to full-file decode, on both 6.x and 10.x recorder generations.
• Index frame counts match ffprobe -count_packets exactly.
• 17/17 tests: all existing decode/parity tests now run through the planned path, plus new tests for writer emission + reader planning parity, partial-blob fetch, no-index fallback, and append-to-legacy-table.

🤖 Generated with Claude Code

---

Update: a second commit (3945b44) rides along — clip_indices as an int64 array instead of a Python list of tuples. On 21M-window corpora the list costs 2.4 GB and ~minutes of pickling per DataLoader worker spawn; measured on the VPT training pipeline this was the difference between 12 workers OOM-killing a 62 GB box and completing at ~2 GB/worker with 2× throughput. Happy to split it into its own PR if preferred — it is logically independent of the GOP index.