Fix version dropdown sync by broadcasting to all users

[lmac-1]

Description

There were a number of issues to do with the version number in the header in collaborative editor when a new version is saved:

1. Saving your workflow didn't update the version number without refreshing the page
2. Weird and difficult to replicate to behaviour where user couldn't update the version dropdown to latest

Aswell as other strange bugs between multiple user sessions when one user saves:

This PR should hopefully fix all of these issues!

Changed broadcast_from! to broadcast! for workflow_saved events to ensure the saving user also receives version updates. This fixes two related issues where the version dropdown would show stale information until page refresh.

The sender needs to receive the broadcast to:

• Update their SessionContextStore.latestSnapshotLockVersion
• Clear their VersionDropdown cache to fetch fresh version list

Closes #3985 and #4024

Validation steps

One user:

1. Open collab editor and make a note of current version of workflow
2. Make a change and click Save
3. Open version dropdown. Expected: Button should still say latest and the version number should have increased by 1.
4. Play around with the version dropdown. Try changing the versions and confirm no errors happen (eg. getting stuck on a version). Make sure to change to latest - 1 and check you don't get stuck there

Two users

1. Repeat the above but make sure that the version numbers are staying in sync between the two sessions
2. Try doing it with FullScreenIDE open and also normal view.
3. Play around and try and break it.

Additional notes for the reviewer

There were some weird bugs where sometimes users would get stuck on latest. You should play around on this branch and try to break it outside of the steps mentioned above.

AI Usage

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

• Code generation (copilot but not intellisense)
• Learning or fact checking
• Strategy / design
• Optimisation / refactoring
• Translation / spellchecking / doc gen
• Other
• I have not used AI

You can read more details in our Responsible AI Policy

Pre-submission checklist

• I have performed a self-review of my 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

[codecov]

Codecov Report

❌ Patch coverage is 50.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 88.84%. Comparing base (14819c9) to head (fa9282e).

Files with missing lines	Patch %	Lines
lib/lightning_web/channels/workflow_channel.ex	50.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4045   +/-   ##
=======================================
  Coverage   88.84%   88.84%           
=======================================
  Files         422      422           
  Lines       19118    19118           
=======================================
  Hits        16985    16985           
  Misses       2133     2133           

☔ 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.

[lmac-1]

Pasting @stuartc's message from Slack:

my apologies, running out of steam for the day, #4045 is top of my list. The one thing I really want to figure out, is why we were using broadcast_from in the first place, because that's pretty intentional - I think your solution is pointed and arguably the way we should do it, but I'm curious about the 'contract' was was supposed to work; the idea behind using broadcast_from vs broadcast was because "we're about to reply about a successful save to the person who asked, and so we should just send back the version with the response to the message". So I want to make sure that there isn't something that isn't quite right on the client side with the success handling of save, if that was always broken, then I mean absolutely lets just use broadcast. The only real "risk" I can think of is that the client who requests a save, will receive the new version potentially before it gets other data, or just afterwards and that "split" between one thing changing and getting another thing means theres a moment when the data isn't technically correct.

I agree - I think this should be investigated further. We should hold off on merging this change for now.

[lmac-1]

Will continue looking into this on Monday. I made some progress locally on potentially handling this better in the frontend. But I found some other bugs that are also on main 🫠

Example:

1. User 1 is viewing latest = version 100
2. User 2 is viewing older version (e.g. version 92)
3. User 1 makes updates and saves a new version (so latest is now 101)
4. User 2's canvas updates to "Loading workflow.." and stays stuck on loading (clears if you refresh, or if user 1 makes an update and saves a new version 102)