orders: report the order's cumulative fill on order_status, not the last print (ibx#315)

[userFRM]

Stacked on #322. The first commit is that PR; review this one from its second commit.

Summary

• order_status was given the size and price of the print that triggered it, where the callback's contract asks for the order as a whole. Argument 3 (filled) received the print's quantity and argument 5 (avgFillPrice) its price. Argument 8, lastFillPrice, received the same price — the one place it belonged.
• IB's contract is filled cumulative, avgFillPrice volume-weighted across every print, lastFillPrice this print.
• A 300-share order filling in three 100-share prints should report filled=100 avg=P1 → filled=200 avg=(P1+P2)/2 → filled=300 avg=VWAP. It reported filled=100 three times, at three different prices each presented as the average.
• Any average-cost or P&L calculation reading avgFillPrice is wrong whenever an order fills in more than one print, which above a round lot is most of the time. filled never reaches the order quantity, so completion detection on that field never fires.

Closes #315.

Change

The gateway sends both numbers on every execution report — CumQty (14) and AvgPx (6). They were already parsed, but only into the execution record, never into the status callback.

They now travel on the fill itself. Reading them from the order cache at dispatch time would have been a smaller change, but a second print arriving between the push and the drain would report its cumulative against the earlier fill; carrying them with the event keeps each one self-consistent. A report that omits either field falls back to the print, which is what the callback reported before.

Every consumer, not just the one the issue named

• Python compat client — dispatches the same drained fill through its own order_status and had the identical pair.
• Open-order snapshot — both clients stored the print as the order's filled quantity, so after a partial fill the push callback said filled=200 while reqOpenOrders said filled=100 for the same order.

Tests

One end-to-end assertion pins the whole callback string, so it covers filled and avgFillPrice together:

order_status:42:PartiallyFilled:200:100:150.5

Reverting the dispatch produces ...:100:100:151, which is the reported bug exactly. Two more tests drive an execution report through the handler and assert the drained fill's cumulative pair comes off tags 14 and 6 rather than 32 and 31, and that it falls back to the print when neither is present.

Test plan

• cargo test --offline --lib — 814 passed. The 2 failures are config::expiry_tests::{named_zone_converts_with_dst, instant_round_trips_to_wire}, which fail on the base commit too: the host has no legacy timezone files (fixed separately in config: resolve the legacy timezone names IB states its times in (ibx#335) #336).
• cargo check --offline --features python — clean.

🤖 Generated with Claude Code

[userFRM]

Four corrections in <this branch>.

Two integration targets stopped compiling. Adding fields to Fill broke twenty struct literals across tests/scenarios.rs and tests/hot_loop_lifecycle.rs, which cargo test --lib never builds. Both compile now, and the gate for this branch covers every target rather than the library alone.

A debug hook removed. An IBX_WIRE_CAPTURE println had been left in the fill path from wire-capture work; it is out, and the branch is clean of it throughout its history.

Scope trimmed to the message. The commit had also carried an unrelated server-tag redesign, byte-identical to the one in #286, under a title about filled quantity. Stripped to what the message claims.

A misindented field corrected to rustfmt.

The functional change is unaltered: order_status reports cumulative filled quantity rather than the unfilled remainder, and LeavesQty remains correct at both of its production uses.