Runs slow editor work off the MingaEditor GenServer's input critical path, serializing the work per lane so a resource that tolerates only one in-flight operation at a time (e.g. the git index) never has two operations racing.

The single editor process owns input dispatch, GUI action handling, state mutation, and pre-render housekeeping. If an action runs slow work (git commands, filesystem walks) inline, later keypresses, clicks, and renderer writebacks queue behind it. run/3 keeps that work off the critical path:

1. The caller does a cheap state transition (e.g. set a "Discarding…" status).
2. run/3 starts the work in a Task if the lane is idle, or appends it to the lane's FIFO queue if a previous op is still running.
3. The editor keeps handling input while the Task runs.
4. When the Task finishes it sends {:async_action_result, lane, token, result} back to the editor, which applies it (when current?/3) and then advance/2s the lane: the next queued op starts, or the lane goes idle.

A lane identifies a serialized resource. Operations on one lane run strictly one at a time, in the order they were requested. This is the load-bearing invariant for mutating resources: two git add/git reset calls can never fight over .git/index.lock, because the second only starts once the first has finished and its result has been applied. Latest-wins (drop the older op) would be wrong here — the older op's mutation already ran; serialization runs every requested op exactly once, in order.

safely/1 captures a raise/exit/throw in the work function as {:error, reason} so a failing action can never crash the editor; the lane still advances afterwards, so one bad op cannot wedge the queue.