fix(workflow): a save's response must not overwrite a newer local edit (WorkflowPersistService)

### What happened?

Every save applies its response as the workflow's metadata: the workspace autosave (`workspace.component.ts`), the menu's own save (`MenuComponent.persistWorkflow`: rename, description, revert) and the Canvas -> Form View switch's save. Saves are sent one at a time since #8456, so a response can land after a newer local edit and overwrite it:

- Rename the workflow while an autosave is in flight: the autosave's response puts the old name back (until the rename's own save answers).
- Click Form View, then rename while the switch's save is out: the rename's save is queued behind the switch's, the switch navigates when its own save completes, and the full-page load aborts the rename's save (metadata edits do not emit `workflowChanged()`, so the hand-over does not wait for them).

Deferred from #8456 on review (threads on `menu.component.ts:692` and `:231`): the rule belongs in `WorkflowPersistService`, the one place every save goes through, not in one caller.

### How to reproduce?

1. Open a workflow on the operator canvas and make a graph edit (an autosave starts).
2. Before it answers, rename the workflow in the title bar.
3. The title flips back to the old name when the autosave's response is applied.

Or: click Form View and rename during the hand-over's save; the rename is lost.

### Proposed fix

In `WorkflowPersistService`: do not apply (or hand back for applying) a response a newer local edit has overtaken, for every caller alike -- e.g. a revision per save, or apply from the response only the fields that still match what was sent; and let the Form View hand-over wait for the save queue to drain rather than for its own save only.

### Version/Branch

main, after #8456.

### Commit Hash

main

### Browsers

All

### Relevant log output

n/a