feat: sunsetting legacy editor

[doc-han]

Description

This PR sunsets the legacy editor

Closes #4402

Validation steps

Manual QA — Legacy editor sunset

Redirects

• /projects/:id/w/:wid/legacy redirects to the collaborative editor
• /projects/:id/w/new/legacy redirects to the new-workflow flow
• Legacy URL with query params still loads (no 404/error)

Legacy users

• A user previously on the legacy editor now lands on the collaborative editor
• No "switch to legacy editor" control anywhere
• No legacy deprecation warning shown

Collaborative editor (regression)

• Open existing workflow (diagram, nodes, edges render)
• Create workflow (template + from scratch), save works
• Add/edit/delete job, trigger, edge — persists after reload
• Real-time sync works across two browsers
• Job editor (Monaco) edits save
• Manual run: pick input, run, see result on canvas
• Credentials modal works
• Webhook auth modal works

AI Assistant

• Panel opens
• Job code mode returns a streamed answer
• Workflow template mode generates/edits a workflow
• Chat history loads + paginates
• Disclaimer prompt works for a new user
• Retry a failed message

Additional notes for the reviewer

1. (Is there anything else the reviewer should know or look out for?)

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

[github-actions]

Security Review ✅

• S0 (project scoping): LegacyRedirectController (lib/lightning_web/controllers/legacy_redirect_controller.ex:15-21) only issues a local redirect and reads no project data; the redirect target WorkflowLive.Collaborate still enforces :project_scope via on_mount.
• S1 (authorization): N/A — the only new endpoint is a redirect gated by [:browser, :require_authenticated_user] (lib/lightning_web/router.ex:146,261-262); authorization continues to be enforced at the redirect target, and the removed switch_to_legacy_editor handler is dead code with no policy surface.
• S2 (audit trail): N/A — the migration (priv/repo/migrations/20260629143825_clear_prefer_legacy_editor.exs) drops a per-user UI preference key, not a project/instance configuration resource that requires an audit entry.

[lmac-1]

@doc-han I am blocking out some time today to go through this 🙏🏻

[lmac-1]

Hey @doc-han, looking good! The deleted Elixir modules have zero dangling references, so that's great.

But assets/js/editor - the legacy editor directory - isn't touched at all in this PR, because the collaborative editor still depends on two files in it. We should resolve this now:

1. Copy magic-completion.ts and es5.min.dts.js into the collaborative editor and repoint the imports. CollaborativeMonaco.tsx and loadDTS.ts currently import both files from assets/js/editor
2. Extract DEFAULT_TEXT out of assets/js/editor/Editor.tsx. This is currently used by usePlaceholders.ts import that one constant. Pull it into a small shared constants file so Editor.tsx has n remaining importers either.
3. Once 1 and 2 are done, delete assets/js/editor entirely, including lib/es5.dts.js and lib/es5.min.dts.js
4. Delete the dead .job-editor-panel CSS in assets/css/app.css as the only component using it was already removed
5. Add a new CHANGELOG.md entry. It belongs in a "Removed" entry and should mention that we are removing the user-facing setting (prefer_legacy_editor) and retires public URLs (/w/:id/legacy, /w/new/legacy)

By the way, I still haven't done manual testing, but happy to do some after these points are addressed :)

[elias-ba]

Hey @doc-han, really clean sunset - I went digging for the scary stuff (dangling refs to the deleted modules, whether the collaborative editor and its AI still stand on their own) and it all holds up nicely 🙌 I'm building on @lmac-1's review rather than repeating it, so I've skipped the changelog + the assets/js/editor cleanup since she's got those covered.

A couple of extra things from me:

• Deep links - left an inline on the redirect controller. Old ?a=<run> bookmarks won't follow the run anymore. More a question than a blocker.

• A test I think we lost by accident - deleting the legacy trigger_test.exs also took the only coverage of the passwordless / SSO webhook-secret reveal in WebhookAuthMethodFormComponent, and that component is still alive (mounted in collaborate.ex and project settings). The surviving SSO tests are for reauth/profile, not the webhook reveal. Since it's a secret-disclosure path, could we port those 1-2 tests onto the surviving component ?

• A bit more dead code to sweep while we're in here - on top of Lucy's list: workflow_live/components.ex still has workflow_diagram/1 (renders phx-hook="WorkflowDiagram", a hook that isn't registered anymore), plus create_job_panel/1 and panel/1 with no callers, and ui_metrics.ex only logged events the deleted JS used to emit. editorUrlConversion.ts also has no prod caller now - though if we reuse it for the deep-link thing above, it earns its keep 🙂

Nothing blocking from my side once Lucy's points land. Thanks for taking this one on, it's a big one 💪

[elias-ba]

Hey @doc-han, nice and tidy PR 🙏 One thing I bumped into here: we forward the raw query string, but the old editor and the collaborative one use different param names. So an old bookmarked run link like /w/:id/legacy?a=<run_id>&m=history redirects to /w/:id?a=<run_id>..., and the collaborative editor only reads run= (see collaborate.ex handle_params), so the run isn't followed - the user just lands on a blank editor. Funny thing is we already have this exact mapping in assets/js/utils/editorUrlConversion.ts (a -> run, s -> job/trigger/edge, m -> panel), it's just client-side. Do you think it's worth mapping at least a -> run here so shared run links keep working ? Not a blocker, more a question.