Collaborative editor gets permanently stuck after a save error with no field to correct (silent data loss)

Most save errors in the collaborative editor are fine — a field-level validation
error (name already taken, bad cron, etc.) shows against the field, and you clear
it by editing the field.

The problem is the class of save error that isn't tied to a field — a :base error,
like the workflows_pkey constraint failure from #4830. There's nothing to edit to
clear it, and it disables the save button. That's a deadlock: the only thing that
would clear the error is a successful save, but the error is what's disabling save.

It's made permanent because the error is written into the shared document state
(the Y.Doc errors map, persisted), so it replays on every load. The save button
stays disabled with the "unsaved changes" dot, and it survives leaving and
re-entering the editor — even a full reload comes back stuck. The only way out is
"Reset to Latest Snapshot" in the workflow settings, which discards everything
edited since.

Why it matters:

• A single transient reconnect (see #4830) can leave a user's editor permanently
  unsaveable, with no obvious recovery.
• Since #4829 downgraded the underlying crash to a toast, there's no error signal
  anymore — so this is effectively silent data loss of every edit made after the
  workflow was first created.

How to reproduce:

• Use the reconnect case from #4830: create a new workflow, save, force the
  collaboration socket to reconnect without reloading, then edit and save again —
  the save fails with a "could not be saved due to a conflicting or missing
  reference" toast.
• Reload the page. The editor still shows unsaved changes with the save button
  disabled, and stays that way until you Reset to Latest Snapshot.

Likely cause / area:

• Validation errors are an observed Y.Doc map in WorkflowStore; the server-side
  :base error gets merged into it and persisted to the document, so it replays on
  every load. A transient/per-client server error probably shouldn't become
  durable CRDT state.
• The save-button gating needs a look — a :base error with no field to fix
  shouldn't be able to deadlock the editor — along with recovery UX (a wedged doc
  should arguably self-heal on a clean reload).

Related: follow-on from #4830 (its reconnect path is the easiest trigger), but
distinct — this failure mode remains even once the insert-vs-update routing in
#4830 is fixed, because it's about how field-less save errors are stored and
surfaced.