Don't redirect to runs page after clicking run

[taylordowns2000]

Description

This PR fixes the workflow canvas to stay on the page after clicking "Run" or "Retry" instead of redirecting to the history page. It also tracks the run ID in the URL (?run=...) so the run selection persists, adds a fallback to the history store's active run when LiveView strips the client-side URL param, and gives in-progress steps a blue highlight on the canvas (matching the "running" chip color in the mini history panel).

Closes #4198

Validation steps

1. Open a workflow in the canvas editor
2. Click "Run" from the header or the manual run panel — you should stay on the canvas, see a success toast, and see &run= appear in the URL
3. Watch the running step highlight blue (border + fill + spinning icon) while executing, then transition to green/red on completion
4. After the run completes, the run should remain selected (no flicker/disappearing)
5. Click "Retry" — should work, stay on canvas, update the URL to the new run ID
6. Click "Retry" again — should still work (previously silently failed on second attempt)
7. Open the full-screen IDE and run/retry from there — existing behavior should be unchanged (run viewer panel opens, etc.)

Additional notes for the reviewer

1. The URL run param can be stripped by LiveView push_patch since build_url only knows about server-managed params (s, m, v, etc.). The diagram now falls back to the history store's activeRunId and restores the URL param via an effect. This is a band-aid — longer term we may want LiveView to preserve unknown query params. (@lmac-1 , @stuartc , is this at all related to your work on the flickering/strangeness in the canvas?)
2. The isRetryingRef bug was a missing reset in the else branch (canvas flow) of handleRetry — the onRunSubmitted path reset it via the pendingRunId effect, but the no-callback path never did.
3. New test files: styles.test.ts (node colors), CollaborativeWorkflowDiagram.url-fallback.test.tsx (URL resilience), plus 4 new tests in useRunRetry.test.tsx (canvas flow + regression).

AI Usage

Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):

• I have used Claude Code
• I have used another model
• I have not used AI

You can read more details in our
Responsible AI Policy

Pre-submission checklist

• I have performed an AI review of my code (we recommend using /review
  with Claude Code)
• I have implemented and tested all related authorization policies.
  (e.g., :owner, :admin, :editor, :viewer)
• I have updated the changelog.
• I have ticked a box in "AI usage" in this PR

[taylordowns2000]

this is the change - don't redirect away from the canvas!

[taylordowns2000]

same here - don't redirect!

[github-actions]

Security Review

⚠️ Automated security review did not complete.

Claude hit the max-turns limit or encountered an error before posting findings.
A manual review of S0 (project-scoped data access), S1 (authorization policies),
and S2 (audit trail coverage) is recommended for this PR.

See the workflow run for details.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.57%. Comparing base (f6f0fad) to head (f798b53).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4608      +/-   ##
==========================================
- Coverage   89.59%   89.57%   -0.02%     
==========================================
  Files         444      444              
  Lines       21558    21558              
==========================================
- Hits        19314    19311       -3     
- Misses       2244     2247       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[midigofrank]

The URL run param can be stripped by LiveView push_patch since build_url only knows about server-managed params (s, m, v, etc.). The diagram now falls back to the history store's activeRunId and restores the URL param via an effect. This is a band-aid — longer term we may want LiveView to preserve unknown query params. (@lmac-1 , @stuartc , is this at all related to your work on the flickering/strangeness in the canvas?)

@taylordowns2000 I don't understand this concern. build_url is a thing of the past, in the legacy liveview. The new liveview (collaborate.ex) doesn't do any push_patches, unless embbended inside credential live components. All query params are handled in the react app

[midigofrank]

Nicely done