ccp: let a duplicate execution suppress the fill, not the whole report (ibx#330)

[userFRM]

Stacked on #323 (which is stacked on #322). Review this one from its third commit.

Summary

• Deduplication exists to stop a fill being counted twice. It was implemented as an early return from the entire handler, so everything after the fill block went with it — the order and contract cache update, and the terminal block that pushes the completed order and calls context.remove_order.
• A replayed execution carrying a terminal status therefore never retired its order. It stayed in open_orders indefinitely: req_open_orders kept returning an order that was filled, and no completed-order record was produced.

Closes #330.

Reachable in ordinary operation

The gateway replays recent executions at session start, and #317 shows each of those messages is currently delivered twice within the same session — so the second copy of a final fill lands here with the order still open.

Stale open-order state is what cancel-all loops and re-entry guards read. An order that shows as working forever is the input that makes those act.

Change

A duplicate skips only the booking — the position update, the Fill event, the execution record. The rest of the report is processed as it would be for any other frame. The status has already been applied by the time the fill block is reached, so the state machine is the part that must not be short-circuited.

Test

A partial fill is booked, then the same ExecID is replayed carrying the terminal status. The fill is not counted twice, and the order still reaches its terminal state and is reported completed. Restoring the early return fails it.

Test plan

• cargo test --offline --lib — 817 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]

Strengthened the test to assert the status notification, not just the removal.

The property this change turns on is that a duplicate still lets the terminal status reach the application. Treating the duplicate as though it had booked a fill would swallow that, because the status notification is suppressed whenever a fill was reported instead — and the original test could not tell the difference, since it only checked that the order had been removed.

It now pins exactly one OrderUpdate carrying Filled for the right order, plus the completed-order record, so suppressing the notification fails it.

The wider "and nothing else" surface — the rich-order cache write, terminal removal for Cancelled and Rejected, the OrderUpdate and CompletedOrder payloads — is untested, but all of it predates this change and none of it is what this commit alters, so I have left it alone rather than growing the diff.

[userFRM]

Closed four mutations the tests were letting through, one of which was the whole point of the change.

The position was never asserted. Making the duplicate arm move the position again passed the entire suite — that is precisely the harm deduplication exists to prevent, and nothing caught it. The test now pins the position, the filled quantity on both the status update and the completed-order record, and the event channel, which every other test here passes None for. Emitting a second Fill to a user callback was invisible for the same reason.

The empty-ExecID path had no coverage anywhere in the repo. Dropping the !exec_id.is_empty() short-circuit records the empty string once and then silently suppresses every later fill that arrives without an id — real fills, dropped as duplicates. Two frames with no ExecID now have to book twice.

A late duplicate could put a finished order back on the open list. The enrichment block had no guard against a stale status, so a duplicate of an earlier partial arriving after the terminal rewrote the cache to PartiallyFilled, and req_open_orders reported a completed order as working until the terminal's own duplicate restored it. Self-healing given ordinary delivery shapes, but visible to a polling thread in between. The block now refuses to overwrite a terminal status with an open one.

Filed #344 for the one finding that is not this change's to fix: the ExecID window is 1024 entries, so a replay batch deeper than that double-books its head. The same probe behaves identically before this commit, so it is the bound rather than anything here — but #317's double delivery makes it easier to reach than it looks.