This commit addresses three bugs related to multi-venue support:

Bug #2 (Medium): Take Profit Reconciliation Doesn't Fan Out
- Changed DealSnapshot.ActiveTakeProfit from *OrderSnapshot to []OrderSnapshot
- Updated snapshot building to collect ALL active take-profits across venues
- Modified ReconcileTakeProfits to iterate and reconcile each venue independently
- Added cancelTakeProfitBySnapshot and reconcileActiveTakeProfitBySnapshot helpers
- Location: filltracker/service.go:156-282

Bug #3 (Medium): Fill Tracker Unbounded Memory Growth
- Added CleanupStaleDeals method to remove completed/inactive deals
- Integrated periodic cleanup (every 10 minutes) in main event loop
- Removes deals with no activity for >1 hour and all orders complete
- Location: filltracker/service.go + cmd/recomma/main.go

Bug #4 (Low): Replay Logic Edge Case
- Documented edge case where venue additions mid-deal may miss replays
- Added inline comment suggesting periodic reconciliation for production
- Location: engine/engine.go:286-292

The take-profit fan-out fix ensures that when a deal has orders across
multiple venues, all venues' take-profits are reconciled correctly,
preventing stale orders on non-primary venues.

The memory cleanup prevents unbounded growth of the fill tracker's
in-memory state by periodically removing fully completed deals.

Updated all test assertions to use the new ActiveTakeProfits slice instead
of the single ActiveTakeProfit pointer. Changes include:
- Replace NotNil checks with Len(slice, 1) assertions
- Replace Nil checks with Empty(slice) assertions
- Access first element via [0] where needed

Critical fixes for multi-venue take-profit reconciliation:

Issue #1 (P1): Each venue's take-profit was being sized to the GLOBAL net
position instead of that specific venue's position. This caused oversized
exit orders (e.g., if venue A had 60 and venue B had 40, both would try
to exit 100, totaling 200 and overshooting inventory).

Fix: Added calculateVenuePositions() to compute net position per venue
by summing filled buy/sell quantities for each venue identifier. Each
venue's take-profit is now correctly sized to match only its position.

Issue #2 (P1): ensureTakeProfit was only called when NO active take-profits
existed. If one venue had an active TP, other venues without TPs would
never get them created, leaving the multi-venue fan-out incomplete.

Fix: Changed logic to iterate through ALL venue positions and reconcile
or create take-profits for each venue independently. Now checks per-venue:
- If venue has position but no TP: create one
- If venue has position and TP: reconcile size
- If venue has no position but TP exists: cancel it

Location: filltracker/service.go:155-215

Critical bug: calculateVenuePositions was skipping ALL reduce-only orders,
including filled take-profits. This caused venues with fully-exited positions
to still report positive net quantities, leading to infinite TP recreation.

Example of the bug:
  Buy order:    +100 units (filled)
  TP order:     -100 units (filled, reduce-only)

  WRONG (before): Skip TP because reduce-only → venueNetQty = +100
  ReconcileTakeProfits sees +100, creates new TP
  Next cycle: still +100, creates another TP (infinite loop!)

  CORRECT (now): Include TP filled qty → venueNetQty = 0
  ReconcileTakeProfits sees 0, cancels any active TPs

The confusion was thinking we should exclude TPs from position calculation,
but we should only exclude UNFILLED quantities. Using FilledQty automatically
handles this:
- Filled TPs: FilledQty > 0, correctly reduces position
- Active TPs: FilledQty = 0 or partial, doesn't affect net calculation

This matches the original behavior where snapshot.Position.NetQty included
all fills (including reduce-only).

Location: filltracker/service.go:246-278

Critical P1 bug: adjustActionWithTracker was comparing individual venue
take-profits against the global Position.NetQty, causing mismatches in
multi-venue scenarios.

Problem:
  Venue A: 60 units position, TP remaining = 60
  Venue B: 40 units position, TP remaining = 40
  Global:  100 units net

  adjustActionWithTracker checks:
    Does 60 == 100? No
    Does 40 == 100? No

  Falls through to sizing logic → tries to set TP.Size = 100
  Oversizes venue TPs until ReconcileTakeProfits corrects them

Root cause: adjustActionWithTracker is called BEFORE fanning out to venues,
so it doesn't have per-venue position data. It only sees global net qty.

Solution: Detect multi-venue scenario (multiple active TPs) and skip the
fast-path sizing logic. Let ReconcileTakeProfits handle all multi-venue
sizing correctly with its per-venue position calculation.

Behavior:
- Single venue (0-1 active TPs): Fast path applies global sizing ✓
- Multi-venue (2+ active TPs): Fast path defers to reconciliation ✓
- ReconcileTakeProfits: Always uses correct per-venue sizing ✓

This prevents the engine from oversizing venue TPs while still allowing
the fast path to work for single-venue deals.

Location: engine/engine.go:524-604