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

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.