bridge: a completed order does not return to the open book (ibx#262)

[userFRM]

Problem

Nothing remembered that an order had reached a terminal state, so a replayed frame put it back into the open book.

push_order_info was a bare insert with no ordering rule, and drain_open_orders filters on the string it writes. The reconnect open-order burst racing a fill — or any message the gateway resends — made req_open_orders report a completed order as live. A strategy then re-manages a position it already has, or cancels an order that no longer exists, with the open-order snapshot corroborating the wrong picture.

Why the cached status cannot carry it

Two ways a status-only guard is bypassed:

• Completing an order evicts its cache row. The replayed frame finds nothing to refuse and inserts itself. That is the ordinary path, not an edge case.
• A cached string is overwritten by the next terminal report. A report landing between the completion and the replay erases the evidence, and the replay then passes.

What this changes

A bounded set of completed order ids carries the knowledge instead, recorded where the completed-order record is already written and surviving the eviction. It is capped and oldest-first, because a session completes orders indefinitely; the width only has to outlive a reconnect's replay of recent activity, which is what resurrects an order.

The rule covers every status the engine treats as ending an order's life — Filled, Cancelled and Rejected are the three it acts on by removing the order from its book. Inactive is not among them, because it returns to working when the condition holding the order clears, and neither is Uncertain, which states the opposite of a conclusion.

A trade cancel (150=H) or trade correction (150=G) restates an execution the gateway has already reported and can legitimately return a filled order to a working quantity. That is the gateway's own statement, not a replay of an older one, so those two execution types write through a separate entry point that supersedes the completion rather than being refused by it.

Tests

• a_completed_order_is_not_returned_to_the_open_book — all three terminal statuses, all four open ones.
• a_completion_outlives_the_cache_row_it_evicts — the ordinary completion path.
• an_intervening_report_does_not_erase_the_completion — Filled → Cancelled → Submitted.
• a_trade_correction_can_reopen_a_completed_order — and the order stops being remembered afterwards.
• a_fill_still_writes_over_a_working_status — the ordinary direction, so the guards are not passing against a cache that refuses everything.
• the_completed_memory_is_bounded — capped, oldest evicted first.

Each fails by name against a compiling reversion of the production change it covers.

Closes #262.

Test plan

• Mutation: removing the completed-id memory fails a_completion_outlives_the_cache_row_it_evicts by name.
• Mutation: narrowing the terminal set to Filled fails a_completed_order_is_not_returned_to_the_open_book.
• Mutation: leaving the id remembered after a correction fails a_trade_correction_can_reopen_a_completed_order.
• Mutation: removing the cap fails the_completed_memory_is_bounded.
• Positive control: a_fill_still_writes_over_a_working_status, so the guards are not passing against a cache that refuses everything.
• cargo check --offline clean on --lib, --lib --features python, --bins, --examples, and each integration target individually.
• tests/ib_paper_compat compared against a clean checkout of the base commit — identical sorted diagnostic sets.
• cargo test --offline --lib — only the two known config::expiry_tests failures, which fail on the base commit for missing legacy tzdata (fixed separately in config: resolve the legacy timezone names IB states its times in (ibx#335) #336).