delta-sync

[ashleychandy]

Description

Implements auction delta sync to reduce solver payload size by sending incremental updates instead of full orderbook snapshots. This lays the foundation for Unified Auction by introducing structured change events and a driver-side replica that can consume deltas while still serving full auctions to solvers.

Changes

• Refactor solvable orders caching to emit structured change events used internally by autopilot.
• Add delta-sync infrastructure and replica logic in the driver, plus metrics and health/readiness tweaks.
• Extend solver/driver DTOs and headers to support delta sync protocol versions.
• Add delta-sync e2e coverage and integration wiring.

How to test

1. cargo nextest run -p e2e local_node_delta_sync_update_pipeline_integration --run-ignored ignored-only --test-threads 1 --failure-output final

Fixes #4207

[gemini-code-assist]

Code Review

This pull request introduces a delta-sync mechanism to reduce payload sizes for solver auctions. The changes are extensive, adding new API endpoints for snapshots and streaming updates, a driver-side replica for auction data, and extending DTOs to support the new protocol. The implementation appears robust, with considerations for security, performance, and resilience. I've found one high-severity logic issue in the fallback handling for thin requests when the replica is unavailable.

[gemini-code-assist]

When body_mode is Thin and the replica is not ready, the current logic incorrectly handles correctly-formed thin requests.

A thin request body (with an empty orders array) will cause parse_full_solve_request to succeed. The code then proceeds with this empty auction, bypassing the else block which contains the necessary logic to use the replica (with retries/bootstrap). This leads to missed solving opportunities.

To fix this, you should check if from_body.orders is empty after parsing. If it is, you should proceed to the replica-handling logic in the else block instead of returning the empty auction.