Fix run_rule(): clicking the menu item only opens a confirmation modal, never runs anything

The user reported runs logged as "success" locally weren't showing up
in MassPrice's own Activity Log. Live-debugged directly against
production: clicking the dropdown's "Run Rule" item opens a
confirmation modal ("Are you sure you want to continue?") rather than
running the rule immediately. Confirmed by network capture — without
clicking the modal's #Confirmation_Run button, zero requests fire, no
error is thrown, and the rule silently never runs. Every prior
"success" in run_history.json for real production traffic was
therefore a false positive.

Verified the fix live: clicking through #ConfirmationModal's
#Confirmation_Run now fires a real POST /Rule/Run request.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H6TgffxTvYhqxykAbVQg2v

CLAUDE.md

@@ -44,12 +44,25 @@ tool is confirmed working, so there's exactly one thing triggering runs.
   id/name pairs (cached to `rules_cache.json`, refreshed via the
   Dashboard's "Refresh Rules" button or on first boot). `run_rule(id)`
   finds that rule's `li.rule.widget-rule` row, clicks its
-  `.dropdown-ellipsis` three-dot toggle, then clicks the row's
+  `.dropdown-ellipsis` three-dot toggle, clicks the row's
   `a.run-rule[data-rule-id=...]` item — mirroring exactly what a human
-  does in the UI. **No public API was found or used** — the "Run Rule"
-  click handler is JS/AJAX-bound (no plain href) and its request is
-  almost certainly anti-forgery-token protected, so automation drives
-  the real page rather than replaying a raw HTTP POST.
+  does in the UI — **then must click through a confirmation modal**
+  (`#ConfirmationModal` → `#Confirmation_Run`; the same generic modal
+  is reused for Delete Rule etc., so the confirm click is scoped to
+  that specific modal instance). That confirmation step is not
+  optional or cosmetic: confirmed by live testing that skipping it
+  fires **zero** network requests and the rule silently never runs,
+  even though the initial dropdown click "succeeds" with no error —
+  an earlier version of this code did exactly that and every reported
+  "success" was a false positive for a real stretch of production use.
+  If a future site redesign changes this modal, watch for the same
+  symptom: local history says success, MassPrice's own Activity Log
+  never gets a matching entry. **No public API was found or used** —
+  the "Run Rule" click handler is JS/AJAX-bound (no plain href, a
+  delegated jQuery handler on `document.body`, not the element itself)
+  and its request (`POST /Rule/Run`, confirmed by live network capture)
+  is almost certainly anti-forgery-token protected, so automation
+  drives the real page rather than replaying a raw HTTP POST.
 - **Session persistence** — a Playwright `storage_state` (cookies +
   localStorage) is saved to `/data/auth_state.json` and reused across
   runs: scheduled runs never touch the login form at all, they just load