integration: live diagnostics for end markers on dump-then-delta streams

[wboayue]

Summary

Live diagnostics for when TWS sends end markers on the streams that send an initial dump and then pushes changes: account_summary, account_updates, account_updates_multi, positions, positions_multi. Written while reviewing #957. Both tests are #[ignore]d. They only print findings, apart from one sanity check that each stream ends its initial dump.

END_MARKER_OBSERVE_SECS=420 END_MARKER_FILL=1 \
  cargo test -p ibapi-integration-async --test end_markers -- --ignored --nocapture

• end_markers_after_initial_dump: merges the five streams into one timeline and prints each frame's arrival time and type (row, end marker, notice, error, closed), followed by a summary per stream. END_MARKER_FILL=1 buys 1 front-month ES at 20s and sells it at 60s, so the run sees pushes that follow fills. This needs Globex open.
• account_summary_end_markers_by_tag_set: requests the regular tags, $LEDGER:ALL, and both, each on its own connection.

Findings

All runs used one paper account with group All through IB Gateway, on 2026-10-05. Accounts with sub-accounts, named groups and TWS are untested.

• All five streams send an end marker after the initial dump and never again. No marker followed the pushes after the fills (~21s, ~61s) or the 3-minute periodic push (~241s).
• account_summary sent two end markers in 5 of 6 runs of end_markers_after_initial_dump, and in all 4 runs of account_summary_end_markers_by_tag_set. The first run, a 30s smoke test, had one. The frame recorder (IBAPI_RECORDING_DIR) logged 1 request out and 2 AccountSummaryEnd frames in, so our client did not duplicate a frame. The recorder logs each frame after it is read from the socket. A byte-level capture (IBAPI_RAW_CAPTURE_DIR) was not run.
  • regular tags: 48 rows, End, End
  • $LEDGER:ALL: 75 rows, End, the same 75 rows again, End
• Each account_summary push arrives within one second, and pushes are at least 40s apart.
• Unresolved: after cancel().await on two summary requests, a third request on the same connection gets 322 even 10s later. A fresh connection works. That's why the second test opens a connection per case.

Test plan

• cargo clippy -p ibapi-integration-async --tests -- -D warnings
• cargo fmt --check
• Ran both tests against the paper gateway, including the 420s run with fills