fix(canvas): a new document starts unlocked, and the edit lock blocks every user edit (v0.21.3) #334

The bug

After File → New, the new, empty document is still edit-locked when the previous document was locked: the lock control stays pressed, the canvas cannot be dragged or deleted from, and the empty-canvas hint still says "Drag a piece from the top bar onto the canvas". A reload keeps the lock. Measured on production v0.21.2 (c5e7d8f) from all four ways a document becomes locked: the Early MMO template (it opens locked by design), a template locked by hand, an imported file with recommendedRunConfig.canvasLocked: true, and a share link made from a locked document opened in a second browser. An unlocked document is unaffected.

While locked, some changes still go through: a palette click adds a node (which can then be neither moved nor deleted), Insert module adds its nodes (97 to 107 in the MMO template), and the toolbar Undo button restores the previous document.

Cause

• graphStore.newGraph() empties the graph, the selection, the frames and the import records, but never resets uiStore.canvasLocked. Only the document load paths reset it (mcStore.applyRecommended: file import, share link, the desktop Templates menu, the phone's template menu). The lock is also kept in localStorage on purpose, so it survives a reload.
• The same newGraph() is called by File → New, by starting a temporary session without carrying the document (switchToTemporary(false)), and by "Delete work data" in a personal browser (deleteWorkData).
• The lock is enforced per control, not at the store: the canvas, the Inspector, the model panels, the Register expression field, the frames and the keyboard shortcuts read it; the toolbar palette, Insert module, the toolbar Undo / Redo buttons, the Data import and refresh wizards and Apply proposal do not.
• e2e/canvas-lock.spec.ts seeds every case with newGraph() immediately followed by applyRecommended(...) through the dev bridge, the step the real New never takes, so no test reached the bug.

The contract (decided)

• After File → New, after starting a temporary session without the document, and after Delete work data, the new document is always unlocked.
• Every whole-document replacement is a document boundary: File → New, a template, an imported file and a share link. After it, the undo / redo history is empty, so Undo and Redo are disabled and Undo can never go back to the previous document. The confirmation dialog before the replacement is the safety net.
• While locked, every user edit is blocked: palette add (click and drag), Insert module, drag, delete, cut, paste, duplicate, the Inspector, undo and redo, and every other command that changes positions, structure or data.
• While locked, these stay available: selection, pan and zoom, Focus and the other view settings, run and Step (and the values they change), copy, export, share, and unlocking.
• Focus mode is a global view setting and stays as it is across New.
• The phone stays view-only, as today (docs/mobile.md §MV3a).

Every entry point that changes the document

Read from the code at c5e7d8f (every call of a document-changing graphStore action outside the store and the tests), and measured where marked.

The fix guards the editor's mutation and history policy in one place that every user edit passes through, so a new entry point cannot forget the lock, and keeps the per-control disabling for what the user sees. That one place explicitly lets three things through: a whole-document replacement (New, a template, a file, a share link), the runtime updates of run, Step and Monte Carlo, and unlocking.

Tests

• Through the real UI, from a locked document: File → New, Storage and privacy → a temporary session without the document, and Delete work data each leave an unlocked, empty document with Undo and Redo disabled, also after a reload.
• After a template, an imported file and a share link are opened, Undo and Redo are disabled, and Ctrl+Z does not bring the previous document back.
• While locked, each blocked entry point in the table leaves the content digest unchanged; each allowed one still works, run and Step included.
• The existing lock tests keep passing; the seed that hid the bug is not the only path any more.

Out of scope

• How the lock control looks and is named: fix(canvas): the edit-lock control shows locked and unlocked at a glance, without colour (v0.21.3) #335, tracked separately but released together with this issue as v0.21.3, in one pull request (this issue's behaviour first).
• The rail's other toggles' naming.

Related: #330 starts (v0.22.0) after this release and the v0.21.4 silhouette work.