feat(python): expose updated_fragment_offsets in the Update operation binding

[pengw0048]

Summary

Operation::Update.updated_fragment_offsets (#6650, #7432) is not reachable from Python: the Rust-to-Python export drops the field, and the Python-to-Rust conversion hardcodes None. This PR wires the field through the Python bindings as dict[int, bytes].

The bytes are the portable RoaringBitmap serialization, the same encoding as proto field 10 (#7432). This keeps dense offset sets compact and avoids materializing one Python int per matched row. A Python RoaringBitmap wrapper type (#7695) can replace the raw bytes later.

Changes

python/python/lance/dataset.py

• Add updated_fragment_offsets: Optional[Dict[int, bytes]] = None to LanceOperation.Update, with attribute documentation.

python/src/transaction.rs

• Python to Rust: extract the dict and deserialize each value with RoaringBitmap::deserialize_from. Invalid bytes raise ValueError. A missing attribute (objects predating the field) extracts as None.
• Rust to Python: serialize each bitmap with RoaringBitmap::serialize_into and pass the resulting dict[int, bytes] to the dataclass.

Test plan

• test_update_with_commit_updated_fragment_offsets: commit an Update carrying offsets for two fragments, read it back with read_transaction, and verify a byte-identical round trip through proto field 10.
• test_update_with_commit_rejects_invalid_offset_bytes: a commit with invalid bitmap bytes fails with ValueError.

[lance-gatekeeper]

✅ Gate recommendation: approve.

This closes the Python transaction-binding gap at the existing wire boundary: populated offset bitmaps round-trip as compact portable bytes, absent legacy fields remain None, and malformed bytes fail with fragment context. Keeping raw bytes is preferable to expanding dense bitmaps into Python integers while the dedicated bitmap wrapper remains separate.

[Xuanwo]

Thank you!

[jerryjch]

@Xuanwo @pengw0048 I have a PR on the Java JNI side, can you please help review #6748?