Edit in sandbox: create or join a sandbox from a live workflow

[elias-ba]

Implements #4859. From a live workflow, "Edit in sandbox" opens a picker to either branch a new sandbox from the current live version or join an active one, then lands the user in the sandbox editor with that workflow's trigger live and its own endpoint. The parent project is untouched; changes come back through promotion in a later slice of the epic.

What's included

• A header action "Edit in sandbox" on a live workflow (non-sandbox project only), and a sandbox badge shown when editing inside a sandbox.
• A picker dialog: create a new sandbox (optional name, defaults to a derived name) or join one of the parent's active sandboxes, listed last-edited first with their collaborators. Join is disabled for a sandbox that doesn't contain this workflow.
• Two channel events backing it. Creating clones the parent project (the existing full-clone provisioning), then promotes the edited workflow to live inside the sandbox. The other cloned workflows stay draft, so a workflow's state stays coherent with its triggers. The sandbox copy remains editable because the live read-only lock only applies outside a sandbox.
• Server-side errors (permission, usage limit) surface their real message in the picker, including the limit upsell, rather than a generic toast.

Demo

1. On a live workflow, click Edit in sandbox to open the picker.
2. Create new provisions a full-clone sandbox, lands in the sandbox editor with the workflow editable and a sandbox badge.
3. The workflow's trigger is live in the sandbox with its own endpoint; the parent is unchanged.
4. Reopen the picker from another live workflow and the active sandbox is listed to join.

Scope and follow-ups

Reuses the existing :provision_sandbox permission (owner/admin/editor) and the :new_sandbox usage limit. There's no last-editor field on a project, so the list sorts by last-edited time and shows collaborators.

Two things deliberately left for their own slices rather than half-built here: refining what the header shows inside a sandbox (suppressing the draft/live controls and adding Promote) belongs with the promote work (#4861); and hiding the action client-side for users who can't provision (today the server enforces it and the picker surfaces the reason) needs a permission flag on the session context.

The who-can-edit-in-sandbox permission model and what "join an active sandbox" should mean access-wise are product calls worth a quick confirm with the feature owners before this leaves the epic branch.

Additional notes for the reviewer

[github-actions]

Security Review ✅

• S0 (project scoping): New list_active_sandboxes_for_editing/2 in lib/lightning/projects.ex:1913 filters on parent_id from socket.assigns.project (authorized at channel join, workflow_channel.ex:1352-1416), and the workflow lookup is scoped to those sandbox_ids; promote_cloned_workflow/3 filters by the just-created sandbox.id, so no cross-project read or write is reachable.
• S1 (authorization): handle_in("edit_in_sandbox", ...) gates on Permissions.can?(:sandboxes, :provision_sandbox, user, parent) (workflow_channel.ex:1194), which lib/lightning/policies/sandboxes.ex:66 resolves to editor/admin/owner on the parent — matching the existing policy; list_sandboxes is a read confined to children of the already-authorized parent project, consistent with list_workspace_projects/2.
• S2 (audit trail): N/A — the handler reuses the pre-existing Projects.provision_sandbox/3 and Workflows.go_live/2/save_workflow flows; no new config-resource write path is introduced that bypasses an existing audit step.