feat: expose granular trace event targets

[beinan]

Summary

• Add granular tracing targets for Lance event categories under lance::events::....
• Preserve the original tracing target in Python log passthrough so LANCE_LOG can filter individual event types directly.
• Document the new event targets and add Python regression coverage for target-specific log filtering.

Testing

• PATH=/Users/beinan/.rustup/toolchains/1.94.0-aarch64-apple-darwin/bin:$PATH cargo fmt --all -- --check
• git diff --check
• PATH=/Users/beinan/.rustup/toolchains/1.94.0-aarch64-apple-darwin/bin:$PATH cargo check -p lance-core -p lance-io -p lance-index -p lance -p lance-datafusion
• PATH=/Users/beinan/.rustup/toolchains/1.94.0-aarch64-apple-darwin/bin:$PATH cargo check --manifest-path python/Cargo.toml
• uv sync --python 3.12 --no-install-project
• .venv/bin/maturin develop --uv -v
• uv run --no-sync --python 3.12 pytest -q python/tests/test_log.py::test_lance_log_filters_trace_event_targets python/tests/test_tracing.py::test_tracing_callback
• uv run --no-sync --python 3.12 ruff format --check python/tests/test_log.py python/tests/test_tracing.py
• uv run --no-sync --python 3.12 ruff check python/tests/test_log.py python/tests/test_tracing.py

[codecov]

Codecov Report

❌ Patch coverage is 92.30769% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
rust/lance-io/src/object_store/throttle.rs	92.30%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[westonpace]

I'm a fan of this change but I'm hoping we can do it without modifying existing targets (to add events::) because that change would be disruptive to us.

Also, semi-related, but I've been thinking we should move more (if not all) of our log statements to tracing events. Having both a "log stream" and a "trace event stream" is pretty confusing.

[beinan]

For the Azure request-id concern: the final object-store error is preserved through LanceError(IO), and I added regression coverage that an Azure-style x-ms-request-id present in the object-store error text survives; response headers that object_store::RetryError does not expose would still need an upstream object_store change.

[westonpace]

Awesome, thanks!

[westonpace]

I'm surprised the mock store actually includes these

[beinan]

I think I mocked the response msg somewhere 😆

[beinan]

@westonpace can we merge?