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>

frontend/src/hooks/useFetchSymbolData.ts

@@ -40,6 +40,9 @@ export function useFetchSymbolData(options: UseFetchSymbolDataOptions = {}) {
       queryClient.invalidateQueries({ queryKey: ['fundamentals', symbol] });
       queryClient.invalidateQueries({ queryKey: ['sr-levels', symbol] });
       queryClient.invalidateQueries({ queryKey: ['scores', symbol] });
+      // Fetch re-runs the scanner → setups/confidence change. Refresh both the
+      // per-ticker trades (['trades', symbol]) and the Overview list (['trades']).
+      queryClient.invalidateQueries({ queryKey: ['trades'] });
 
       if (invalidatePipelineReadiness) {
         queryClient.invalidateQueries({ queryKey: ['admin', 'pipeline-readiness'] });