Refine handling of OrderBookDeltas

[faysou]

Pull Request

NautilusTrader prioritizes correctness and reliability, please follow existing patterns for validation and testing.

• I have reviewed the CONTRIBUTING.md and followed the established practices

Summary

Summary

• Refined the handling of OrderBookDeltas across the platform, improving support for historical data requests and on-the-fly backtesting.
• Implemented to_deltas in the Rust OrderBook model to allow capturing the current book state as a series of deltas (a snapshot).
• Added request_order_book_deltas to the Actor and updated subscription methods to support snapshot intervals via interval_ms.
• Enhanced DataEngine with filtering logic for historical OrderBookDeltas, including the ability to replay deltas from the start of a UTC day to evolve a snapshot to a specific start time.
• Updated the Databento adapter to support historical order book deltas and added comprehensive unit and acceptance tests.

Changes

• crates/model/src/orderbook/book.rs: Added to_deltas to convert current book state to an OrderBookDeltas snapshot.
• nautilus_trader/common/actor.pyx: Added request_order_book_deltas and updated subscribe_order_book to support interval_ms.
• nautilus_trader/data/engine.pyx: Implemented _filter_historical_order_book_deltas for snapshot evolution and date range filtering.
• nautilus_trader/data/messages.pyx: Added RequestOrderBookDeltas and updated SubscribeOrderBook.to_request.
• crates/adapters/databento: Added support for historical order book deltas in the Databento historical client.
• tests/: Added unit tests for the data engine and messages, and an acceptance test for order book deltas in backtests.

Test plan

• Verified the changes with new unit tests in tests/unit_tests/data/test_engine.py and tests/unit_tests/data/test_messages.py.
• Added a new acceptance test in tests/acceptance_tests/test_backtest.py.
• Validated the functionality with the provided notebook example examples/backtest/notebooks/databento_test_order_book_deltas.py.

Related Issues/PRs

Type of change

• Bug fix (non-breaking)
• New feature (non-breaking)
• Improvement (non-breaking)
• Breaking change (impacts existing behavior)
• Documentation update
• Maintenance / chore

Breaking change details (if applicable)

Documentation

• Documentation changes follow the style guide (docs/developer_guide/docs.md)

Release notes

• I added a concise entry to RELEASES.md that follows the existing conventions (when applicable)

Testing

Ensure new or changed logic is covered by tests.

• Affected code paths are already covered by the test suite
• I added/updated tests to cover new or changed logic