ccp: report the orders a reconnect does not explain (ibx#251)

[userFRM]

Problem

An order working when the CCP link drops is marked Uncertain, and that is the end of it. The engine stops believing the status and tells nobody, so the API layer goes on reporting the pre-disconnect status for the whole outage — and req_open_orders keeps asserting it.

Quantities are carried as they are

OrderUpdate's filled and remaining quantities are floating point. Both dispatchers already cast them to f64 on the way to the callback, so the integer was only an intermediate hop — and it truncated: a half-share order outstanding reported nothing outstanding, which is the opposite of true. A 2.5-share order with one filled now reports 1.5 remaining rather than a rounded stand-in.

A disconnect arriving before the first execution report has no quantity to state at all, so it reports the unset sentinel this codebase already uses for that rather than inventing one.

What this changes

The flip is reported. mark_orders_uncertain mutated the book silently. The disconnect now publishes an order status update for each order it withdraws, carrying filled and remaining quantities and the identifiers a caller keys on — broker id and bracket link, read back from the enriched cache rather than zeroed.

The snapshot stops contradicting it. collect_open_orders unions the client's own records with the cached view, and the cached view still said the order was working, so a caller asking which orders were open was told the opposite of what the callback had just told them. The union exists to add orders this client has no record of, such as one placed in an earlier session; it now skips the ones whose status this client has withdrawn, and only those, so a genuinely newer cached status still merges.

What this deliberately does not do

Deciding what became of an order absent from the recovery push is #384, not this. Absence does not identify an outcome:

• it cannot separate a cancellation from a rejection;
• an order carrying a decimal quantity holds zero in the integer quantity field, so a completeness test reads it as filled when nothing filled;
• an execution for the order can still arrive after the push ends, and it cannot book if the order has been retired from the book to record a verdict — the fill and the position move are lost, which is worse than the state being unknown.

So the order stays Uncertain and stays in the book, where any real message supersedes it, and the caller is told the status is unknown rather than told something that may be wrong. Deciding those outcomes wants a positive statement from the gateway — a status request on reconnect, or a capture establishing what the push guarantees.

The remaining items the original filing bundled with this are #384 (terminalizing from absence) and #385 (a PendingSubmit ack deadline); the HMDS warm-up re-arm it also mentioned is fixed in #367.

Closes #251.

Tests

• a_disconnect_tells_the_application_the_status_is_no_longer_known — the withdrawal reaches the caller with quantities and identifiers intact.
• an_order_the_reconnect_does_not_explain_still_books_its_execution — an order the push never mentions still books a fill and moves the position.
• a_cached_status_does_not_override_what_this_client_knows — withdrawn statuses are not re-imported; an order from an earlier session still merges, and a newer cached status still merges.

Each fails by name when its production change is reverted.

No new wire traffic: this consumes what the gateway already sends.

Test plan

• Mutation: dropping the identifiers from the withdrawal callback fails a_disconnect_tells_the_application_the_status_is_no_longer_known by name.
• Mutation: emitting nothing on disconnect fails the same test.
• Mutation: removing the order on disconnect fails an_order_the_reconnect_does_not_explain_still_books_its_execution.
• Mutation: widening the union guard to every locally tracked id fails a_cached_status_does_not_override_what_this_client_knows.
• 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).