fix(scanner): properly enforce balance thresholds, scale limits, and …

[cbaezp]

Description

The Problem:

Extremely active algorithm / whale wallets were functionally suffocating the bot's architecture. Wallets processing hundreds of trades per minute were overrunning the listener's memory boundary (limit: 20), and wallets with massive historic footprints were triggering the Scanner's 10,000 bounds safety net because the old SDK natively pulled dead/inactive positions. Furthermore, when the Strategy Engine mathematically choked out valid positions (e.g. $0.00 balances or < $1 scalar crushing), those trades were permanently stuck in the visual Monitoring state on the UI without explaining why they were skipped.

The Solution:

Real-Time Listener Expansion:

• Boosted the WebSocket/polling trades endpoint limit from 20 to 1000. The engine will now capture the entirety of high-frequency spikes and cleanly debounce them without physically dropping block trades.
• Scanner API Migration & Scaling:
• Ripped PositionsRequest out of the sweep logic and rebuilt it around a raw reqwest integration directly to the PolyMarket API. This allows us to inject the &active=true parameter, instantly filtering out thousands of closed trades and preventing the loop from breaking prematurely.
• Raised the Scanner iteration bailout cap from 20 (10,000 limits) to 100 (50,000 limits) for massive breadth.
• Engine Rejection UI Persistence:
• Plumbed early-stage Strategy bounds failures (buy_size < MIN_ORDER_SHARES & Insufficient USDC balance) down into the persistent BotState.
• Wired the Scanner sizing module to cleanly identify trades that drop mathematically below the $1.00 USD execution floor and push those explicitly.
• Exported the engine_reason into TargetPosition so the Rust TUI and React Frontend natively render exactly why a valid Monitoring trade was rejected on the orderbook.