Settle a pending DCA order with no venue id by looking it up at Coinbase by client_order_id #1017

Summary

Since #1016, a resting DCA BUY (pending / partially_filled) blocks that rule's catch-up so two buys are never in flight. When place_order raises (a timeout, a reset connection), the row stays pending with no venue order id. reconcile skips rows without a venue id, so nothing ever settles it.

#1016 gives the operator a manual way out (a local-only keel orders cancel behind a typed yes) and notifies daily while the rule is blocked. This issue is the automatic fix the design called in scope and deferred: look the order up at the venue.

What to build

• Persist the venue-facing client_order_id on the order row before place_order is called (today it only comes back in place_result, so it is lost on raise).
• In reconcile, for a live pending row with no venue id but a client_order_id, ask Coinbase whether an order with that client id exists (list/historical orders filtered by client id), and settle the row from the answer: filled → filled with the venue id; not found after a grace period → a terminal "never placed" status.
• Never settle a row as "never placed" on an unreadable answer.

Why

A stuck row otherwise blocks the rule's buys until a human notices the daily banner and runs the manual cancel.

Related

• Design: docs/superpowers/specs/2026-11-06-rail-17-venue-read-and-dca-catchup-design.md ("Designer's call" on pending orders)
• Rail 17's 7-day attestation TTL cannot cover a 14-day DCA cadence; vetoed windows are never retried #1010, Rail 17 reads Coinbase; skipped DCA buys retry until the next window and alert on macOS (#1010) #1016