ccp: a cancel rejected as unknown retires the order (ibx#252)

[userFRM]

Stacked on #322 — review the tip commit only.

Problem

FIX CxlRejReason 1 is UnknownOrder: the gateway is stating that the order does not exist on its side.

handle_cancel_reject restored it to working anyway. The restore ran first and unconditionally, and only afterwards did anything branch on the reason — then it removed the shared-cache row. Engine and cache were left asserting opposite things.

The engine's own view governs subsequent cancels, modifies and reconnect bookkeeping, so a phantom order persisted there with no cache row to make it visible — the inverse of the usual stale-cache problem and harder to notice. It compounds after a reconnect, where a cancel aimed at an order that no longer exists is the expected shape.

What this changes

The reason is read before the status is chosen, and read as a positive statement rather than an absence. A missing or unparseable tag 102 is synthesized as -1 and says nothing, so it takes the same path as the reasons that do mean the order is still working and the cancel arrived at the wrong moment.

An unknown order is retired — terminal status, removed from the book, cache row dropped.

Holding the record in a non-working status instead is not an option: those are excluded from the open-order count that guards instrument reclamation, so the slot could be handed to another contract while a retained order still pointed at it, and a late fill would move the wrong position.

A fill that races the rejection is recoverable, on the terms the untracked-fill path from #322 sets — hence the stacking. The execution has to carry its contract id, because nothing else says which instrument moved, and it must not be resend-marked, because a replayed execution for an order this session does not track is history rather than news. One carrying neither is dropped, as it already was for any order removed from the book ahead of a late fill.

No synthetic status update is queued. The cancel-reject is the report, and both dispatchers drain fills ahead of order updates; an update queued here would reach a caller after the fill that raced it, stating the order was gone when they had just been told it filled.

Both dispatchers retire the client's own record when they deliver that rejection. collect_open_orders unions the client's records with the cached view, so retiring only the engine's left the order being reported by the very surface this issue is about.

Tests

• an_unknown_order_rejection_retires_the_order — order and cache row gone, cancel-reject delivered, no synthetic update.
• an_execution_racing_an_unknown_order_rejection_still_books — the fill books and the position moves.
• any_other_rejection_leaves_the_order_in_place — stated reasons that mean it is working, and the absent/unparseable case.

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

Closes #252.

Test plan

• Mutation: treating UnknownOrder like every other reason fails an_unknown_order_rejection_retires_the_order by name.
• Mutation: leaving the order in the book fails the same test.
• Mutation: retiring on any non-zero reason fails any_other_rejection_leaves_the_order_in_place.
• an_execution_racing_an_unknown_order_rejection_still_books covers the case retiring the record could have cost.
• 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).