Drop over-progressed setups via live R:R; refresh trades on fetch

Answers "why does a too-far-progressed setup still show": setups are only
recalculated by the scheduled R:R scan and manual fetch; at creation
entry == current price (0% progress), so over-progression is a
between-scans drift effect and must be judged at read time.

- /trades now attaches current_price (latest close per ticker).
- Qualification drops setups whose R:R recomputed from the current price
  falls below min_rr — i.e. price already ran toward target (reward
  consumed) or through the stop. Reuses the existing min_rr threshold
  instead of a separate progress %; far cleaner (a 3:1 is already ~1:1
  by 33% progress). Skipped for historical setups (no current_price).
- Fix: useFetchSymbolData now invalidates the trades queries, so a fetch/
  recompute actually refreshes confidence/setups in the UI (was the cause
  of the stale 100% confidence lingering after recompute).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

app/schemas/trade_setup.py

@@ -47,4 +47,5 @@ class TradeSetupResponse(BaseModel):
     actual_outcome: str | None = None
     outcome_date: date | None = None
     evaluated_at: datetime | None = None
+    current_price: float | None = None
     recommendation_summary: RecommendationSummaryResponse | None = None