fix(frontend): keep canvas edits made during a save, fix Windows-flaky specs (#14765)

* fix(frontend): keep canvas edits made during a save

An edit made while a flow save was in flight was silently discarded.

`saveFlow` adopts the PATCH response into `useFlowStore.currentFlow`, which
is the baseline the next autosave diffs against. When the response belongs to
a request that started before the edit, adopting it makes the edit look
already-persisted, the queued autosave short-circuits, and the change never
reaches the backend. Nothing surfaces the loss until the flow is reloaded.

Adopt the response only when the canvas still holds the graph that request
carried. The store swaps the nodes/edges arrays on every change, so identity
is an exact "nothing moved while we were away" check, and the unchanged case
behaves exactly as before.

Found via the Windows nightly, where shared-playground.a11y published a flow
whose edge never persisted. Reproduced on macOS by holding the PATCH response
until after the edge was connected: node 2 and the edge were both lost.

* test(frontend): fix Windows-flaky playwright specs

Three separate causes behind the Windows nightly failures.

A sidebar drag can be swallowed whole: the HTML5 drag sequence starts on a row
React is still re-rendering after the search, the drop never reaches the
canvas, and no node appears — silently, so the spec only fails much later on a
handle that does not exist. That is how Windows lost the Text Input node in
stop-building. Reproduced on macOS at 20x CPU throttling, where the first drag
after the legacy toggle drops. `addComponentFromSidebar` now retries, but only
when nothing landed at all, so a slow-but-successful drop is never duplicated.
stop-building drops its five hand-rolled drags for that verified helper.

lock-flow does four lock/unlock round trips plus twenty click-and-assert
iterations — one minute here, right on the five-minute wall on Windows, where
every step costs 3-5x as much. Marked slow there; nothing about it is
Windows-specific except the pace.

Teardown's in-flight request drain gets the same treatment: 2s is not enough
for Windows to finish the last MCP server list and template refresh, and the
wait only costs that long when something really is still pending.

mcp-server-starter-projects needed no change — the settings navigation helper
it failed in was already rewritten onto test ids on this branch.