fix: keep GetSnapshotWithError supported, caller-owned checkpoints, reusable layout worker

[rendis]

This PR fixes three problems that came from combining #25 and #26. All three should be fixed before the next release.

1. Keep GetSnapshotWithError supported (docs only)

ExQuantumMachine.GetSnapshotWithError was added during the current unreleased cycle (#22/#23). #25 deprecated it before any release shipped it.

• experimental/machine.go: the Deprecated: notice is replaced by a note pointing to GetSnapshotContext for callers that need cancellable lock waiting or callback reentry detection.
• docs/runtime.md, docs/instrumentation.md: these said "context-free snapshot methods are deprecated", which also covered GetSnapshotWithError. They now name only GetSnapshot and LoadSnapshot.
• CHANGELOG.md: adds a Deprecated section, because Handle snapshot errors and run Studio layout in workers #25's deprecations were not recorded there.

2. Public history checkpoints stay caller-owned (Studio)

In #26, commit-snapshot took ownership of any snapshot returned by the public createHistorySnapshot, to skip a second clone. That breaks the contract #25 documented in docs/studio-performance.md: supplied checkpoints are mutable and caller-owned.

Reproduction on current main: create a snapshot, commit it, mutate snapshot.machineConfig.id, then undo. Undo restores the mutated value.

The fix:

• createHistorySnapshot is copied on commit again.
• Skipping the second clone now applies only to the editor's own drag/gesture checkpoint. That checkpoint is never exposed, so the editor keeps the speed-up from fix: atomic runtime admission, guarded external values, single-clone history commits #26.
• The mechanism lives in the new state/historyOwnership.ts, which is not re-exported from the package.

Tests:

• New test: a public checkpoint mutated after commit does not change what undo restores. It fails on main and passes here.
• New test: the internal checkpoint is stored without a copy, and ownership transfers only once.

3. Reusable layout worker with a fallback (Studio)

In #25 every layout created, initialized and terminated a new ELK worker. Each layout spent 200–400 ms starting the 1.6 MB engine, so small graphs were slower end to end than on the main thread. And if the worker could not load (404, worker-src CSP, cross-origin asset URL), every layout failed and only logged a console.error.

• Reuse. One worker per URL serves all layouts, concurrent ones included (elk-api tags each message with an id). It is released after 60 s idle.
• Fallback. If the worker cannot start or load, the layout runs on the bundled engine on the main thread, and that URL is not retried for the rest of the page session. A worker that crashes after working is discarded; its in-flight requests fall back and the next layout starts a new worker.
• Timeout. After 30 s the request still rejects and the worker is discarded. It does not fall back, because rerunning a stuck graph on the main thread would freeze the UI.
• ELK errors. Errors from an invalid graph are returned unchanged and the worker is kept.

autoLayoutWorker.test.ts was rewritten with 10 tests. They cover worker reuse, falling back on error and messageerror, a throwing Worker constructor, a missing Worker global, a crash after success, timeout, ELK errors, and idle release.

Checked in Chromium against the real ELK worker served by the Vite dev server:

• The initial layout plus three manual ones used a single worker, with no console errors.
• With a broken worker URL, the editor tried it once, logged the fallback warning, and later layouts kept working.

Validation

• Go: go build, go vet, go test ./...
• Studio: lint, typecheck, test (330 + 3 tests), build, Stryker dry-run