fix: Race-safe active_orders cleanup in update_order_status

[keitaj]

Summary

• Replace del self.active_orders[order_id] with self.active_orders.pop(order_id, None) in update_order_status of both OrderManager and MultiDexOrderManager. Prevents KeyError when an order has already been removed concurrently (e.g. by cancel_order/bulk_cancel between the disappeared snapshot and the cleanup loop).
• Improve error log to include type(e).__name__ and the active order count, so cryptic logs like Error updating order status: 398309313821 (which was just a bare KeyError arg) are no longer ambiguous.
• The previous KeyError also re-raised through the broader except API_ERRORS because KeyError is in API_ERRORS, so a single race could trigger both inner and outer error logs.

Changes

File	Change
order_manager.py	update_order_status: use pop(default=None); richer error log
hip3/multi_dex_order_manager.py	Same fix in two cleanup loops (success path + except cleanup)
tests/test_active_orders_race.py	6 new tests covering: race during fills fetch, error path with stale orders, exception-type-in-log assertions

Test plan

• 6 new tests pass
• Full test suite passes (799 tests)
• flake8 clean
• No regressions in existing test_update_order_status.py
• Behavior change is purely defensive — successful cleanups behave identically

🤖 Generated with Claude Code

[keitaj]

Review: Race-safe active_orders cleanup

Defensive fix with clear root-cause analysis. The original bug log (`Error updating order status: 398309313821`) is now fully explained: `KeyError` is in `API_ERRORS`, so a stale `del` would re-enter the broader `except` block and log only the missing key as the exception arg.

---

1. Status assignment before pop (informational)

`order_manager.py` L500-505 and `hip3/multi_dex_order_manager.py` L257-260:

`order.status` is assigned BEFORE `pop()`. This is correct — even if the dict entry is already gone, the in-list snapshot of the `Order` object still gets its status updated. The two operations don't depend on each other. ✓

2. Error log enrichment (informational)

Including `type(e).name` makes future bare-arg exceptions (like `KeyError(123)`) immediately diagnosable. Before:
```
Error updating order status: 398309313821
```
After:
```
Error updating order status (KeyError, 5 active orders): 398309313821
```

3. Race semantics (informational)

The fix is universally correct regardless of whether the race is true cross-thread or just same-thread re-entry (e.g., main-loop calling `cancel_order` between the disappeared snapshot and the cleanup loop). `pop(key, None)` adds no measurable overhead. ✓

4. Test coverage (informational)

6 tests cover:

• Race during fills fetch (concurrent removal mocked)
• Normal path unchanged
• Error path with stale orders in except cleanup
• Exception type appears in log message
• Both `OrderManager` and `MultiDexOrderManager` paths

Real assertions (`order_a.status == OrderStatus.CANCELLED`, `100 not in mdm.active_orders`), no formality. ✓

---

Verdict: LGTM

• No blockers or should-fix items
• Defensive change, no behavior regression on the happy path
• Diagnostics meaningfully improved
• Test scenarios precisely model the production bug

Merging after CI check.