docs: Add 1-minute webhook flooding analysis and solution

CRITICAL: TradingView skipping 5-minute trading signals due to 1-minute alert flood

Root Cause:
- 1-minute alerts fire 180 times/hour (60/hr × 3 symbols)
- TradingView has undocumented webhook rate limiting
- High-frequency alerts cause lower-frequency alerts to be dropped
- 2 confirmed incidents of missed 5-minute trading signals

Impact:
- Missed real trading opportunities (revenue loss)
- 5-minute signals are PRIMARY income source
- 1-minute data collection provides ZERO actual value

Analysis Shows 1-Minute Data Unnecessary:
- Smart Entry Timer: Uses signal data (not cache)
- Position Manager: Uses Pyth WebSocket (not cache)
- Quality scoring: Uses signal data (not cache)
- Adaptive trailing: Uses signal ADX (not cache)
- Market data cache updates are vestigial

Solution:
- PAUSE all 1-minute TradingView alerts (SOL/ETH/BTC)
- 83% reduction in webhook load (180/hr → 36/hr)
- 5-minute signals will arrive consistently
- No functionality loss (all systems use signal data or Pyth)

Files Changed:
- docs/1MIN_SIGNAL_OPTIMIZATION.md - Full analysis and implementation guide
- .github/copilot-instructions.md - Added Common Pitfall #1 (webhook flooding)

Next Steps:
1. Pause 3 1-minute alerts in TradingView (immediate)
2. Monitor 5-minute signal delivery for 24 hours
3. Archive BlockedSignal timeframe='1' data (optional cleanup)

See: docs/1MIN_SIGNAL_OPTIMIZATION.md for complete analysis

.github/copilot-instructions.md

@@ -2674,7 +2674,36 @@ ORDER BY MIN(adx) DESC;
 
 ## Common Pitfalls
 
-1. **DRIFT SDK MEMORY LEAK (CRITICAL - Fixed Nov 15, 2025, Enhanced Nov 24, 2025):**
+1. **TRADINGVIEW WEBHOOK FLOODING (CRITICAL - Discovered Dec 4, 2025):**
+   - **Symptom:** 5-minute trading signals randomly skipped by TradingView, causing missed trade opportunities
+   - **Root Cause:** 1-minute data collection alerts fire 180 times/hour, overwhelming TradingView webhook delivery system
+   - **Mechanism:** TradingView has undocumented rate limiting - high-frequency alerts cause lower-frequency alerts to be dropped
+   - **Real Incidents:** 2 confirmed cases of 5-minute signals not sent due to 1-minute alert flood
+   - **Impact:** CRITICAL - Primary trading signals (revenue source) being blocked by non-essential data collection
+   - **Analysis:** 1-minute data provides ZERO value:
+     * Smart Entry Timer uses signal data (not cache)
+     * Position Manager uses Pyth WebSocket (not cache)
+     * Quality scoring uses signal data (not cache)
+     * Adaptive trailing uses signal ADX (not cache)
+     * Market data cache updates are vestigial from early development
+   - **Solution:** Pause/delete all 1-minute TradingView alerts:
+     ```bash
+     # In TradingView:
+     # 1. Find "SOL-PERP 1min Data Feed" alert → Pause or Delete
+     # 2. Find "ETH-PERP 1min Data Feed" alert → Pause or Delete
+     # 3. Find "BTC-PERP 1min Data Feed" alert → Pause or Delete
+     ```
+   - **Expected result:** 180 webhooks/hour → 36 webhooks/hour (83% reduction), 5-minute signals arrive consistently
+   - **Alternative (if 1-minute trading needed):** Create separate lightweight webhook with strong filters, minimal payload
+   - **Database cleanup:** ~1,408 BlockedSignal records/day can be archived or deleted (10 MB/day savings)
+   - **Files affected:**
+     * `workflows/trading/moneyline_1min_data_feed.pinescript` - Mark as deprecated
+     * `docs/1MIN_SIGNAL_OPTIMIZATION.md` - Full analysis and solution
+     * `docs/1MIN_DATA_COLLECTION_SIMPLE.md` - Add warning about webhook flooding
+   - **Lesson:** High-frequency webhooks (60+/hour) interfere with TradingView's delivery of lower-frequency webhooks. Always test webhook delivery under load before deploying to production.
+   - **Git commit:** "fix: Pause 1-minute alerts to prevent TradingView webhook flooding (2 missed 5-min signals)"
+
+2. **DRIFT SDK MEMORY LEAK (CRITICAL - Fixed Nov 15, 2025, Enhanced Nov 24, 2025):**
    - **Symptom:** JavaScript heap out of memory after 10+ hours runtime, Telegram bot timeouts (60s)
    - **Root Cause:** Drift SDK accumulates WebSocket subscriptions over time without cleanup
    - **Manifestation:** Thousands of `accountUnsubscribe error: readyState was 2 (CLOSING)` in logs