Bulk bid processing

[ZanCorDX]

📝 Summary

This PR changes BiddingService::observe_relay_bids to take a vector of bids to allow bulk bid processing.

💡 Motivation and Context

This should allow the bidder to process more efficiently the bids (eg: generate a single bid from us after processing the vector).

✅ I have completed the following steps:

• Run make lint
• Run make test
• Added tests (if applicable)

[claude]

Claude finished @ZanCorDX's task in 52s —— View job

---

• Read diff and changed files
• Post review feedback

Review

Clean, small PR. The interface change from single to Vec is straightforward and all call sites are updated. A few observations:

1. On-error bid loss in spawn_scraped_bids_and_blocks_subscriber

In bidding_service_server_adapter.rs (lines 241-249), when poll returns an error partway through, bids collected before the error are still forwarded via update_new_bids. This is fine and arguably better than before (where an error mid-poll would lose all bids), but worth noting that partial batches will be sent on error — make sure downstream consumers handle variable-size batches correctly.

2. BiddingServiceClientAdapter::observe_relay_bids still sends one-by-one

In bidding_service_client_adapter.rs (lines 329-333), the client adapter loops and calls self.scraped_bids_publisher.send(bid) individually for each element. This means the bulk benefit doesn't propagate through the client→server IPC boundary — the server side will still receive individual bids. If the goal is end-to-end bulk processing, this adapter would need a bulk send as well.

3. No capacity hint on Vec::new()

In bidding_service_server_adapter.rs line 241, Vec::new() is used without a capacity hint. If typical poll batches have a known or estimable size, Vec::with_capacity(...) would avoid reallocations. Minor optimization, not blocking.

Overall this is a clean incremental change. The main point to consider is item 2 — whether the per-bid send in the client adapter undermines the purpose of this PR.