Whole-content autosave overwrites collaborators' edits to non-shared state (workflowSettings, formBinding)

### What happened?

In collaborative editing, operators/links/positions sync between clients through the Yjs shared model — but two pieces of workflow content do not: `workflowSettings`, and (since #8275) `formBinding`. Each client hydrates a private copy on load (`WorkflowActionService`), and `getWorkflowContent()` re-emits that private copy into every autosave, which persists the **whole** content JSON.

So: client A edits a setting (or the Form View definition) → A's autosave persists it → client B, whose private copy is still the old value, makes any graph edit → B's autosave persists the whole content with B's **stale** copy → A's edit is silently reverted in the DB. A's screen still shows the new value until reload; the overwritten value is recoverable from version history, but nothing tells the users it happened.

`workflowSettings` has had this since collaborative editing landed (low exposure — settings changes are rare one-shot toggles). `content.formBinding` (#8275) widens the exposure: form authoring is a long-lived editing session, so the window where a collaborator's graph edit can clobber it is much larger. First surfaced for formBinding by a Copilot comment on #8304.

Possible directions (not prescribing): move these into the shared model (a `Y.Map` alongside `operatorIDMap` etc.); or merge against the latest persisted content before a whole-content save; or field-level persistence.

### How to reproduce?

1. Open the same workflow in two browsers (A and B), both with write access.
2. In A: change a workflow setting (e.g. the data transfer batch size in the settings panel). A autosaves.
3. In B (without reloading): drag any operator. B autosaves.
4. Reload either browser: the setting is back to its old value — B's save carried B's stale private copy over A's edit.

The same mechanism applies to `content.formBinding` once its authoring UI lands.

### Version/Branch

main