ccp: stop reporting the OCA group as an order's parent (ibx#329)

[userFRM]

Summary

The engine writes the OCA group to tag 583 on the way out, in three places, and read the same tag back in as the parent order id — hashed into the i64 the callback exposes. Both cannot be right.

(583, &oca_group),         // OCAGroup                          ← outbound
let parent_id = parsed.get(&583).map(perm_id_from_fix_order_id) // ← inbound

Closes #329.

Evidence

583 is the group. Two orders placed in group PROBE-OCA-1, then one cancelled — the gateway cancelled the sibling, which is what an OCA group is for:

== placing BUY 1 SPY LMT 100 oca=PROBE-OCA-1 (oid=9401)
== placing BUY 1 SPY LMT 101 oca=PROBE-OCA-1 (oid=9402)
== cancelling oid=9401
[status] oid=9402 Cancelled          ← sibling went with it

The inbound reports carry the group on 583 for both, with distinct order ids:

oid=9401.0   583=PROBE-OCA-1   37=0256d0f1.0001417e.6a698306.0001
oid=9402.0   583=PROBE-OCA-1   37=0256d0f1.0001417e.6a698308.0001

and the parent reported for them was:

[status] oid=9401 PreSubmitted parent_id=9132926678952268133
[status] oid=9402 PreSubmitted parent_id=9132926678952268133

The same non-zero number for two orders that have no parent — the hash of the group name.

Impact

Anything reconstructing order relationships from the callbacks — a bracket tracker, a position attributor, a UI grouping children under parents — reads that as a real link and builds the wrong tree. It never reads as missing data, which is what would make it easy to notice: a non-OCA order has no 583, reports zero, and looks correct. The wrong value appears exactly when a group is in use.

Change

Nothing on the execution report carries a parent order id, so none is reported. An unknown parent is a worse answer than a correct one and a much better answer than a confident wrong one.

Tests

An order carrying an OCA group reports no parent, and its status is still delivered. Restoring the hash fails it.

Test plan

• cargo test --offline --lib — 810 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.
• Mutation check: reverting the fill-path parent fails a_fill_reports_the_parent_the_child_was_given; reverting the preview path fails a_what_if_preview_reports_the_parent_the_child_was_given.
• Not covered: reverting the type-4 dispatch itself fails no test — the route-to-gate step runs inside connect.

🤖 Generated with Claude Code

[userFRM]

Updated in 115d60b. The parent preference now covers all three callback paths, not one.

A fill emits its own order_status from a different branch and never reached the branch that was changed; the margin preview emits a third and hard-coded zero. So a bracket child still reported no parent on the fill callback — the one a caller is most likely to act on. All three now prefer the recorded parent, and reverting any one of them fails its own test by name. Neither of the two missed paths had a test, which is what let the gap through.

One claim corrected. The message said nothing on the report can carry a parent, and that tag 6107 is a client id rather than an order id. The encoder derives 6107 directly from the caller's parent_id, so the second half contradicts this library's own protocol model, and the first was asserted rather than shown. The narrower statement is what holds: the engine reads no parent from the report, so for an order this client placed its own record is the only source. What the gateway does or does not echo is not established here.

The test pinning 6107 as unread stays, and now says what it is — a guard on a different invariant, which passes with or without this change — rather than being presented as evidence for it.

Two smaller items: the status-loop test asserted a parent only for updates it happened to receive, so a case producing none passed by never entering the loop; it now requires exactly one update per case first. And tracked_parent_id was pub on a publicly exported module, widening the API for an internal helper — now pub(crate), with is_order_tracked's doc comment restored to it.

810 pass plus the two config::expiry_tests timezone failures. --features python clean.

[userFRM]

Updated in b4ba91e.

The Python paths now have coverage. Reverting either Python lookup — the fill or the margin preview — left every Rust test passing, so "on both clients" rested on nothing. There are three Python tests now, using the existing _test_* harness. The extension was built and the tests run rather than left unexecuted: all three pass, and reverting the two Python lookups fails the first two by name while the third survives, since it is the positive control. _test_track_order gained an optional parent id, which is what makes a tracked child expressible from Python at all.

On tracked_parent_id visibility: narrowing it to pub(crate) is not a source break. The method does not exist on main — this PR introduces it — so it has never been part of a released surface. Narrowing it inside the same change that adds it keeps an internal helper from widening a publicly exported module's API.

810 pass plus the two config::expiry_tests timezone failures, and the three Python tests. All offline targets clean.