Resolve frame metadata for image sequences and videos

[PaulHax]

Third of a four-PR stack, on top of #1807. Review only this PR's own commits; the base branch
carries #1806 and #1807.

Summary

The shared client engine turning readable TXT/CSV attachments into per-frame values.

Image sequences resolve in order: a column matching media filenames; a literal zero-based frame
column; one uniquely best monotonic source-image-counter column. Videos accept only the literal
zero-based frame contract.

Sparse and out-of-order rows are valid; malformed, duplicate, and out-of-range frame values cannot
overwrite a valid row. Column selection is first-match, not a ranking: the leftmost column that
names at least two of a camera's images wins, and the leftmost integer column that survives the
counter checks wins. A shared multicamera table needs no arbitration — a sibling camera's filename
column names none of this camera's images, so it never qualifies.

Media controllers expose a ready frame context for image-sequence and video consumers. Large-image
datasets keep their attachment for opt-in pipelines but resolve no rows. A shared composable owns
loading, selected-camera precedence, per-frame lookup, and a compact session cache; every camera's
attachment is fetched eagerly and the in-flight load is shared, so switching cameras mid-load does
not re-download. Derived rows are not persisted.

No UI consumes this yet — the panel that does is the next PR. Review it against the unit tests.

Reviewer focus

• Filename matching outranks weaker numeric evidence.
• Literal frame means a DIVE zero-based frame number, never row order.
• Counter inference requires unique, monotonic evidence; ties, resets, and duplicates are rejected.
• Filename inference applies the same tie rule.
• Video resolution cannot fall through to filename/counter heuristics.
• Camera switches and delayed media readiness never serve stale rows; a camera with no capture at
  the current aligned instant shows none.