Investigate: unify editor and export canvas runtimes to eliminate behavioral drift

Read packages/canvas-runtime/src/worker/LuaCanvasRuntime.ts and packages/export/src/runtime/canvas-standalone.ts, then compare their exposed Lua APIs and execution models. Review canvas-inline.generated.ts and bundle-canvas-inline.js while assessing the proposed approaches. Done means documented API differences, feasibility prototypes, a recommendation with tradeoffs, and a migration path preserving editor and export behavior.

Problem

The editor (packages/canvas-runtime) and export (packages/export/src/runtime) maintain independent implementations of the same Lua canvas API. They have different execution models:

• Editor (canvas-runtime): Multi-threaded — Lua runs in a Web Worker, drawing commands are queued and sent to the main thread for rendering
• Export (export runtime): Single-threaded — Lua runs on the main thread, draws directly on the canvas context

Because these are separate codebases implementing the same API surface, features and fixes applied to one are routinely missed in the other. This has happened multiple times:

• Keyboard focus fixes applied only to export
• Browser reserved key handling (F11, F12) applied only to export
• Drag prevention applied only to export
• Audio autoplay policy handling applied only to export

Every canvas feature or bugfix requires remembering to update both implementations — and there's no automated check that catches drift until a user reports "this works in the editor but not in export" (or vice versa).

Goal

Investigate architectural approaches to make the editor and export share a single runtime implementation, so behavioral parity is structurally guaranteed rather than relying on developer discipline.

Possible Approaches to Investigate

A. Editor loads the standalone export runtime

Instead of canvas-runtime's worker-based command queue, the editor could:

1. Generate the same standalone bundle that export produces
2. Load it in an iframe or Web Worker connected to the editor's terminal/canvas
3. The editor becomes a thin shell around the export runtime

Pros: Single runtime = perfect parity. Export is always tested because the editor uses it.
Cons: May lose editor-specific capabilities (breakpoints, step-through, live canvas inspection). Performance implications of iframe communication. Need to investigate latency.

B. Export uses canvas-runtime in a Web Worker

Flip the approach: make the export HTML bundle the worker-based canvas-runtime instead of canvas-standalone.

• Export HTML would include a minimal main-thread renderer + the worker runtime
• Same command queue, same rendering pipeline

Pros: Reuses the more mature canvas-runtime. Single implementation.
Cons: Export HTML becomes more complex (needs worker infrastructure). May impact export file size. Service Worker or inline worker blob needed for single-file constraint.

C. Shared abstract runtime with pluggable backends

Extract the Lua API bindings into a shared module that accepts a "drawing backend" interface:

• Direct backend (for export): calls ctx.fillRect() directly
• Queue backend (for editor): pushes commands to a queue for main-thread rendering

Both canvas-runtime and export import the same API setup code, just with different backends.

Pros: API surface is defined once. New Lua functions automatically available in both contexts.
Cons: Still two code paths for the backend implementations. Backend interface must be carefully designed to not leak abstraction.

D. Shared test suite for behavioral parity

Less architectural, more process: create a shared test suite that runs the same Lua programs against both runtimes and asserts identical output (canvas state, terminal output, audio calls).

Pros: Catches drift automatically. Doesn't require architectural changes.
Cons: Doesn't eliminate the duplication — just catches when they diverge. Still requires implementing features twice.

Investigation Tasks

• Inventory the full Lua API surface exposed by both runtimes — document where they already differ
• Prototype approach A: editor loading standalone export in iframe/worker — measure latency and identify capability gaps
• Prototype approach C: shared API module with pluggable backend — assess feasibility and complexity
• Evaluate approach B: inline worker in export HTML — assess file size and browser compatibility
• Assess approach D as a stopgap regardless of which architectural approach is chosen
• Document architectural recommendation with tradeoffs

Context

• packages/canvas-runtime/src/worker/LuaCanvasRuntime.ts — editor worker runtime (1,932 lines)
• packages/export/src/runtime/canvas-standalone.ts — export runtime (1,629 lines)
• packages/export/src/runtime/canvas-inline.generated.ts — auto-generated bundle from canvas-standalone.ts
• packages/export/scripts/bundle-canvas-inline.js — esbuild bundler for export
• Both implement: __canvas_clear, __canvas_setColor, __canvas_drawImage, __canvas_setFontSize, keyboard/mouse input, audio, etc.

Acceptance Criteria

• Investigation complete with documented recommendation
• Prototype(s) demonstrating feasibility of recommended approach
• Clear migration path that doesn't break existing editor or export functionality