[Data] Install mcap in CI so the MCAP datasource tests actually run

[marwan116]

Description

python/ray/data/tests/datasource/test_mcap.py guards its whole module with
pytestmark = skipif(not MCAP_AVAILABLE), and mcap appears in no requirements file
anywhere in the repo. //python/ray/data:test_mcap has therefore reported success
since the datasource landed in #55716 without executing a single one of its 18 tests.

This PR adds mcap to python/requirements/ml/data-test-requirements.txt — the file
consumed by the Data CI image (ci/env/install-dependencies.sh:303, ci/ci.sh:60) and
by ci/raydepsets/configs/ci_data.depsets.yaml:19 — and regenerates the locks that
depend on it.

Related issues

Related to #65912, which fixes estimate_inmemory_data_size for this datasource. The
two PRs are independent: both carry the identical one-line fix to
test_read_mcap_invalid_time_range, deliberately, so neither blocks the other. Being
byte-identical, whichever lands second should rebase without a conflict.

Related to #61222 (audit and refactor file-based datasource tests), which covers
adjacent ground but not this.

Additional information

What turning the tests on exposed

Three defects were sitting behind that skip. Each is fixed in its own commit here,
because without them the target goes red on its first real run:

1. test_read_mcap_invalid_time_range can never pass. It searches for
   "start_time must be less than end_time"; the code raises
   "start_time (2000) must be less than end_time (1000)". Fails on unmodified master.

2. _should_include_message and _message_to_dict annotate schema as a bare
   Schema, but McapReader.iter_messages() yields
   Tuple[Optional[Schema], Channel, Message] — a channel may declare no schema. Both
   bodies already guard with if schema else None, so this is an annotation fix only.
   It was invisible while mcap was absent: pyrefly could not resolve mcap.reader,
   treated the return as Any, and reported nothing. With the package installed its
   py.typed annotations apply and ci/lint/pyrefly-check.sh fails on the two
   pre-existing call sites in _read_stream.

3. python/requirements_compiled.txt was missing mcap. That file is a separate
   lock from python/deplocks/, compiled by compile_pip_dependencies in ci/ci.sh
   from an input list that includes data-test-requirements.txt.

The dependency itself costs the image nothing

The regenerated locks introduce exactly one package:

mcap==1.4.0 \
    --hash=sha256:0528e2f86a61bfec73779e0628e6cf27af83d01d89e20b27d5ec9f0b556a63ac \
    --hash=sha256:0b48b1cc951b8d5aabd2599e60d410bae4f1be1819094f54117b7cbf6b3ee2e9
    # via -r python/requirements/ml/data-test-requirements.txt

mcap's own dependencies, lz4 and zstandard, are already present via
clickhouse-connect, dask, ray and pyiceberg. Every other changed line across the
ten python/deplocks/ci/*.lock files and requirements_compiled.txt is a # via
comment recording mcap as a new consumer.

How the locks were produced

python/deplocks/*.lock with the repo's own tooling, using the same command the
raydepsets: compile all dependencies job runs:

bazelisk run //ci/raydepsets:raydepsets -- build --all-configs
bazelisk run //ci/raydepsets:raydepsets -- build --all-configs --check
# Lock files are up to date.

python/requirements_compiled.txt could not be regenerated locally:
compile_pip_dependencies returns early on arm64 (ci/ci.sh:20-27). Its four added
lines were reconstructed from the dependencies job's own diff and land at the exact
line numbers it reported — mcap at 1093–1094, zstandard's # via entry at 2712.

Worth knowing for anyone adding a dependency here: the two lock systems are coupled
through a symlink. python/requirements_compiled_py3.10 … py3.13 are all symlinks to
requirements_compiled.txt (only py3.14 is a real file), and
ci/raydepsets/pre_hooks/remove-compiled-headers.sh copies
python/requirements_compiled_py3.13.txt into /tmp/ray-deps/, where it becomes the
constraint the data depsets compile against. So adding a package to
requirements_compiled.txt changes the # via provenance recorded in
python/deplocks/ci/*.lock — uv then lists the package as coming from both the
constraint and data-test-requirements.txt. Regenerating one lock system without the
other leaves the tree inconsistent, which is why this PR has a separate commit for it.

Tests

With mcap installed on unmodified master, the previously-skipped module runs and one
test fails — what the target would have been reporting all along:

1 failed, 17 passed in 15.50s
FAILED test_read_mcap_invalid_time_range
E   AssertionError: Regex pattern did not match.
E    Regex: 'start_time must be less than end_time'
E    Input: 'start_time (2000) must be less than end_time (1000)'

With the fixes in this PR:

PYTHONPATH=python/ray/data/tests python -u -m pytest \
    python/ray/data/tests/datasource/test_mcap.py -v
18 passed in 10.95s

pyrefly, run exactly as ci/lint/pyrefly-check.sh does, reports no errors in
mcap_datasource.py. Lint hooks black, ruff, pydoclint, docstyle, check-ast,
check-import-order, trailing-whitespace and end-of-file-fixer all pass on the
changed files.

size = "small" is left as-is: the 18 tests take ~11s, and test_json is small with
58 tests, so the 60-second budget has ample headroom.

---

AI assistance (Claude) was used for this change. I reviewed every changed line and ran
the commands above locally.

[gemini-code-assist]

Code Review

This pull request adds the mcap dependency to the ML data test requirements and updates the corresponding CI lockfiles. This ensures that the MCAP datasource tests in python/ray/data/tests/datasource/test_mcap.py are actually executed rather than being silently skipped. Additionally, a minor assertion adjustment was made in test_mcap.py to match a more general error message. There are no review comments, and I have no feedback to provide.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 2f6912f. Configure here.}