Updates MULTI_VENUE_BUGS.md to reflect:
- Resolved: SQL duplicate clauses (commit cd763cf)
- Clarified: OrderId is not redundant (tracks 3commas orders)
- Renumbered remaining bugs #1-8 (from #1-12)

Remaining critical issues:
- Bug #1: OrderWork comparability violation
- Bugs #2-6: Scaled orders multi-venue architecture

This commit fixes three critical bugs in the scaled order system related to
multi-venue support:

Bug #2: Hard-coded Default Venue in Queries
- Remove venue_id filter from ListScaledOrdersByOrderId and ListScaledOrdersByDeal
- These queries now return records from all venues instead of just the default

Bug #3: Wrong Venue Assignment in InsertScaledOrderAudit
- Change InsertScaledOrderAudit to use venue/wallet from the OrderIdentifier parameter
- Add fallback to default venue for backward compatibility
- Each audit record now correctly reflects the actual submission venue

Bug #4: Missing Venue Context in Parameters
- Update ScaledOrderAuditParams and RecordScaledOrderParams to use OrderIdentifier
- Add Identifier field to orderscaler.Request
- Update BuildRequest to accept OrderIdentifier parameter
- Change applyScaling to accept OrderIdentifier and scale per-venue
- Refactor engine emission loop to scale each venue independently

The key architectural change is moving from "scale once, apply to all venues"
to "scale per-venue" which ensures each venue gets its own audit record with
the correct venue and wallet information.

Fixes #2-4

This commit fixes three critical bugs in the scaled order system related to
multi-venue support:

Bug #2: Hard-coded Default Venue in Queries
- Remove venue_id filter from ListScaledOrdersByOrderId and ListScaledOrdersByDeal
- These queries now return records from all venues instead of just the default

Bug #3: Wrong Venue Assignment in InsertScaledOrderAudit
- Change InsertScaledOrderAudit to use venue/wallet from the OrderIdentifier parameter
- Add fallback to default venue for backward compatibility
- Each audit record now correctly reflects the actual submission venue

Bug #4: Missing Venue Context in Parameters
- Update ScaledOrderAuditParams and RecordScaledOrderParams to use OrderIdentifier
- Add Identifier field to orderscaler.Request
- Update BuildRequest to accept OrderIdentifier parameter
- Change applyScaling to accept OrderIdentifier and scale per-venue
- Refactor engine emission loop to scale each venue independently

The key architectural change is moving from "scale once, apply to all venues"
to "scale per-venue" which ensures each venue gets its own audit record with
the correct venue and wallet information.

Note: After pulling this commit, run `go generate ./...` to regenerate sqlc code.

Fixes #2-4

Updates MULTI_VENUE_BUGS.md to reflect:
- Resolved: SQL duplicate clauses (commit cd763cf)
- Clarified: OrderId is not redundant (tracks 3commas orders)
- Renumbered remaining bugs #1-8 (from #1-12)

Remaining critical issues:
- Bug #1: OrderWork comparability violation
- Bugs #2-6: Scaled orders multi-venue architecture

Updated MULTI_VENUE_BUGS.md to reflect resolved issues:

Resolved (PRs #75 and #76):
- Bug #1: OrderWork comparability violation
- Bug #2-4: Scaled orders multi-venue architecture

Remaining issues (renumbered #1-4):
- Bug #1: Missing scaled_orders in wallet migration (High)
- Bug #2: Take profit reconciliation fan-out (Medium)
- Bug #3: Fill tracker memory growth (Medium)
- Bug #4: Replay logic edge case (Low)

PRs:
- #75: Removed pointer fields from Action struct
- #76: Fixed multi-venue scaled order handling

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.

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