Fix workflows_pkey duplicate INSERT on collab reconnect, and remove its root cause (#4830)

[stuartc]

Description

This fixes the workflows_pkey duplicate-key crash you'd sometimes hit when reconnecting to the collaborative editor after a save — and then goes after the thing that was actually causing it.

The root cause was that we were resolving "which workflow am I editing, and is it new or existing?" in two completely separate places: once when the channel joins (load_workflow/5) and again on the session save/reset path (fetch_workflow/1). Those two could quietly disagree about whether an id should map to a :built struct (→ INSERT) or a :loaded one (→ UPDATE). So a reconnect that still thought it was "new" would try to INSERT a row that already existed → boom.

So there are two parts here:

1. The immediate fix — the reconnect path heals the join action and reconciles to the saved row, so the next save UPDATEs instead of colliding.
2. The real fix — I pulled all of that resolution logic into one place, Lightning.Collaboration.WorkflowResolver. Both callers now go through it, so they physically can't disagree any more. It also hands back an explicit kind (:new | :existing | :version) so the channel stops trying to guess "is this new?" from the shape of the struct. fetch_workflow/1 and the old NotLoaded poking are gone.

The nice property that closes the bug: a "new" join for an id that already has a row resolves to the existing :loaded row (kind: :existing), so the save routes to UPDATE. No more duplicate INSERT.

Closes #4830

Validation steps

1. Open a workflow in the collab editor, make a change, save it.
2. Force a reconnect (drop the socket / refresh the tab) and save again. Before this, that could blow up with a workflows_pkey duplicate-key error — now it should just save cleanly.
3. Sanity-check the three normal flows still work: creating a brand-new workflow, editing an existing one, and viewing an older version.
4. mix test test/lightning/collaboration/ test/lightning_web/channels/workflow_channel_test.exs — should be green (273 tests here).

Additional notes for the reviewer

A few things worth your eyes:

• The bit that actually closes the bug is the reconcile-by-id behaviour — a "new" action on an id that already has a row comes back as :existing. There's a resolver test pinning this specifically, since getting it wrong would bring the duplicate-INSERT straight back.
• Auth ordering is unchanged: "new" still authorises first, "edit"/version still resolve first. Authorisation stays in the channel; the resolver only does the project-ownership check, and only when it's handed a :project.
• One small tightening: a "new" rejoin for an id that belongs to another project now returns a wrong-project error instead of silently building a fresh struct. Felt like the safer behaviour.
• I kept the #4829 Ecto.ConstraintError rescue in workflows.ex as a backstop — didn't want to remove the belt while adding the braces.
• While moving things around, the reset path briefly lost its "this workflow was deleted" error — I put that back (resetting a soft-deleted workflow returns workflow_deleted again, same as before), with a test.

AI Usage

• 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

[github-actions]

Security Review ✅

• S0 (project scoping): New WorkflowResolver.resolve/3 enforces ownership via check_ownership/2 when a :project opt is passed; both call sites (channel load_workflow and Session.save_workflow/reset_workflow) supply it, so cross-project access still returns :wrong_project. Snapshot-version path's project-from-supplied behavior matches the pre-refactor code at workflow_channel.ex:1191-1212.
• S1 (authorization): No authorization gates moved or removed — Permissions.can(:workflows, :access_read, ...) still wraps every :edit path and Permissions.can(:project_users, :create_workflow, ...) still gates the :new path at workflow_channel.ex:1205,1224,1243; the resolver explicitly defers auth to the channel (workflow_resolver.ex:13-14).
• S2 (audit trail): N/A, no config-resource writes added — Session.save_workflow still delegates persistence to Lightning.Workflows.save_workflow/2 unchanged, so existing audit coverage is preserved.

[codecov]

Codecov Report

❌ Patch coverage is 87.95181% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.4%. Comparing base (1f514b8) to head (2b6fad4).

Files with missing lines	Patch %	Lines
lib/lightning/collaboration/session.ex	60.0%	6 Missing ⚠️
lib/lightning_web/channels/workflow_channel.ex	84.0%	4 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #4841     +/-   ##
=======================================
+ Coverage   90.3%   90.4%   +0.1%     
=======================================
  Files        444     445      +1     
  Lines      22607   22639     +32     
=======================================
+ Hits       20419   20468     +49     
+ Misses      2188    2171     -17     

☔ View full report in Codecov by Harness.
📢 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.