bug(undo-redo): QuotaExceededError when localStorage cap is exhausted by undo/redo snapshots

[Sprexatura]

Summary

A QuotaExceededError: Failed to execute 'setItem' on 'Storage' can surface from various small Zustand-persisted stores (e.g., notification-storage, panel-editor-state) when a user has actively built workflows for some time. The stack trace points to the persist middleware's setItem call on whichever store happened to write next after the origin's localStorage cap was reached.

The store whose throw lands in monitoring is not the actual culprit — it's just the first victim after another store filled the origin's quota.

Root cause

workflow-undo-redo is persisted to localStorage and stores operation snapshots that include full block state. Capacity is MAX_STACKS=5 × DEFAULT_CAPACITY=100 = 500 ops. Active editing of multiple workflows quickly fills the per-stack capacity with snapshots that can be several KB each, occupying the bulk of the origin's ~5 MB localStorage budget.

Once the budget is exhausted, any other persisted Zustand store whose setItem is called next throws QuotaExceededError.

Reproduction (Chromium-based browser, ~5 MB origin cap)

1. Open the workflow editor.
2. Add an agent block and paste a large system prompt (e.g., 5 KB of text).
3. Delete and re-add the block several times. Each cycle pushes batch-add-blocks and batch-remove-blocks operations whose snapshots include the full block state.
4. Across a few workflows (up to 5 stacks as MAX_STACKS allows), the localStorage origin reaches the cap.
5. Take any action that triggers another store's persist (e.g., select a block, dismiss a notification). The next setItem throws QuotaExceededError.

Measurement helper for the console:

```js
const sizes = Object.keys(localStorage).map(k => [k, localStorage.getItem(k)?.length ?? 0])
console.table(sizes.sort((a, b) => b[1] - a[1]))
```

shows workflow-undo-redo occupying the bulk of origin storage in the affected state.

Existing partial mitigations

• PR fix(undo-redo): eviction policy to not have unbounded undo-redo stacks #2079 added an inline safeStorageAdapter to undo-redo's persist middleware, swallowing the quota throw silently for that store — but it does not free the origin budget that other small stores share, so those still throw uncaught.
• PR feat(terminal): migrate from zustand for console terminal logs to indexedDb, incr limit from 5mb to ~GBs #2812 moved terminal-console-store from localStorage to IndexedDB for the same reason (large data).
• PR improvement(localStorage): remove use of local storage except for oauth and last active workspace id #497 explicitly stated the policy to "remove use of local storage except for oauth and last active workspace id". The later introduction of undo-redo's localStorage persistence diverged from that policy.

Proposed fix

Migrate `workflow-undo-redo` to IndexedDB using the same `idb-keyval` pattern as `terminal-console-store` (PR #2812), including a one-time migration that copies any existing data and removes the legacy localStorage key on first module load. PR follows.