chore: checkpoint web Blender migration source, tools and docs

Accumulated uncommitted work: GHOST Web backend, WebGL/GPU web layer,
web workflow engine and protocol, tooling, docs and task records.
Large generated evidence, user-testing archives, build snapshots and
imported test assets remain untracked.

Co-Authored-By: Claude Code <noreply@anthropic.com>

docs/BLENDER_WEB_EXECUTION_CONTROL_PLANE.md

@@ -10,7 +10,8 @@ receipts, hashes, and compact task context. It changes the unit of production wo
 | --- | --- | --- |
 | What runs next | `docs/EXECUTION_QUEUE.md` + its parent manifest | One active, serialized handoff pointer |
 | What is a product capability | `docs/BLENDER_WASM_CAPABILITY_MATRIX_TEMPLATE.json` | User-observable behavior and its proven parity level |
-| What is still covered | `tests/golden/M15-03A/next-task-plan.json` | Legacy regression cases; not a promise of implementation |
+| What is still covered | `tests/golden/WBV2/dynamic-inventory.json` | Source-derived units and conservative verified/unverified state |
+| Historical regression catalog | `tests/golden/M15-03A/next-task-plan.json` | Read-only 6900-entry estimate and regression cases |
 | What was already proven | `tests/golden/<task>/manifest.json` and `tests/golden/corrective/` | Immutable receipts and hashes |
 
 The old corrective handoff is historical evidence. A later queue task is valid only when
@@ -19,16 +20,49 @@ rewritten to make it appear current.
 
 ## Production unit
 
-The production unit is a capability workflow, not an individual Blender operator or
-RNA field. A capability task owns one user-visible mutation and reuses shared command,
-context, resource, Main transaction, history, and case-runner primitives. Its data-driven
-cases may cover related legacy gaps in the same family.
+The production unit is a module-backed capability workflow, not an individual Blender
+operator or RNA field. A module owns a coherent code, transaction, and rollback boundary;
+its capability commands are shared primitives, and its operator inventory rows are
+data-driven coverage cases. A single module task may therefore cover hundreds of related
+operators without creating hundreds of production tasks.
+
+The required relationship is:
+
+```text
+module task -> capability/command -> operator case matrix
+```
+
+An operator ID is never a queue pointer. It maps to exactly one primary module and records
+its context, parameters, desktop oracle, expected mutation, negative boundary, persistence
+expectation, and result status. The historical 6,620+ figure is a catalog-scale estimate,
+not a promise to run 6,620 hand-authored commands; the current inventory has its own exact
+total/pending counts and SHA, recorded in the module manifest.
 
 Every capability task must state its parity level, positive mutation, negative boundary,
 save/reopen behavior, undo/redo behavior, resource budget, and Chromium receipt. A
 `CANCELLED`, `UNSUPPORTED`, metadata-only, snapshot-only, or external-resource result is
 coverage evidence, never a positive feature claim.
 
+### Module completion gate
+
+Module work has a fast feedback loop and a mandatory batch gate:
+
+1. Freeze the module contract and run a small representative positive/negative/reopen set.
+2. Implement the shared production path and prove a real desktop/WASM Main mutation.
+3. Freeze the source and run every mapped operator case through one versioned runner. Shards
+   may run in parallel, but use the same catalog snapshot and deterministic inputs.
+4. Before merge, run the full operator catalog as a sharded regression suite and compare it
+   with the hash-bound baseline. Existing passes may not regress, and new failures/blocked
+   cases require review; unsupported or retained-negative baselines are not treated as passes.
+5. Publish one aggregate manifest containing case counts, shard exit codes, catalog/source
+   hashes, and links to per-case evidence. Any failed, blocked, budget, or hash-drift case
+   keeps the module in progress.
+
+Per-change checks may run only affected cases plus the representative set. A module cannot
+be marked complete until the full matrix has passed; the same matrix is then a scheduled
+regression suite. No operator-specific checker branch, queue slot, or production commit is
+created when the behavior uses an existing module primitive.
+
 ## Lifecycle and gates
 
 ```text
@@ -56,6 +90,8 @@ the task `in_progress` or `blocked`.
   serialized through the parent manifest.
 - A capability implementation should close multiple related legacy cases. Three
   consecutive evidence-only tasks trigger a route review.
+- Module completion is measured by production changes plus aggregate operator coverage,
+  not by the number of operator rows or generated fixtures.
 - Positive and negative cases are generated together. Failure, cancellation, budget, or
   hash drift never advances the successor.
 - Legacy `M16-GAP-*` records stay immutable; migration adds capability coverage references
@@ -63,9 +99,55 @@ the task `in_progress` or `blocked`.
 
 ## Current migration state
 
+The active production queue is the finite function-module plan at
+`tests/golden/WBV2-P1100-000/module-execution-plan.json`. It supersedes the generic
+`WBV2-P*` continuation chain without rewriting its historical manifests. The queue has
+completed the render, scene/mesh, material/animation, non-mesh, nodes/simulation,
+asset, sculpt/paint, editor, object, compositor/sequencer and inventory-gate modules;
+the completed chain now also includes `AUDIO_PARTICLE` (`WBV2-P1105-000`),
+`RIG_ANIMATION` (`WBV2-P1106-000`), `MODIFIER_SYSTEM` (`WBV2-P1107-000`),
+`NODES_GRAPH` (`WBV2-P1108-000`), `IO_FORMAT` (`WBV2-P1109-000`),
+`RENDER_PIPELINE` (`WBV2-P1110-000`), `SCRIPTING_SECURITY` (`WBV2-P1111-000`),
+`ANIMATION_TIMELINE` (`WBV2-P1112-000`), `SHADER_MATERIAL` (`WBV2-P1113-000`),
+`GREASE_PENCIL` (`WBV2-P1114-000`), `CURVE_SURFACE_EDITING` (`WBV2-P1115-000`),
+`STORAGE_RECOVERY` (`WBV2-P1116-000`), `SIMULATION_CACHE` (`WBV2-P1117-000`),
+`UI_INPUT_INTERACTION` (`WBV2-P1118-000`), `LIBRARY_WORKFLOW` (`WBV2-P1119-000`),
+`VOLUME_NANOVDB` (`WBV2-P1120-000`), `PAINT_STROKE` (`WBV2-P1121-000`),
+`ENGINE_RUNTIME` (`WBV2-P1122-000`), `GLB_ROUNDTRIP_REPAIR` (`WBV2-P1123-000`),
+`HISTORICAL_HASH_DRIFT` (`WBV2-P1124-000`),
+`GEOMETRY_NODES_ALLOWLIST_REPAIR` (`WBV2-P1125-000`),
+`GREASE_PENCIL_VIEWPORT` (`WBV2-P1126-000`), `TRACKING_MASK` (`WBV2-P1127-000`) and
+`SEQUENCER_MOVIE_CODEC` (`WBV2-P1128-000`) and
+`CORE_SCENE_GRAPH_SETTINGS` (`WBV2-P1129-001`) and
+`UI_EDITOR_VIEW2D_STATE` (`WBV2-P1130-001`) and
+`CURVE_TOPOLOGY_EDITOR` (`WBV2-P1131-001`).
+The Audio/Speaker/ParticleSettings gap was solved with a Web-safe Scene IDProperty
+retention path in authoritative Main; desktop Audaspace remains disabled because its
+Emscripten symbols are unavailable. New work is added only as a source-backed module
+with Chromium, negative and recovery gates. Queue authorization, batch indexing,
+repeated generic markers, and build-only smoke are not feature completion.
+The historical 6,900-entry inventory remains read-only. The current source-derived
+inventory is `tests/golden/WBV2/dynamic-inventory.json`; its unit count and source-tree
+hash are regenerated from Blender 5.2 source, while `5200` is a non-binding planning
+estimate. Units remain unverified until explicit behavior evidence binds them.
+
+## Project completion audit
+
+The current migration epoch is a verified capability slice, not full Blender parity.
+It contains 38 completed source-backed function modules plus the bridge/root and
+successor-authorization tasks; the module plan is terminal at `WBV2-P1131-001`.
+The historical 15-family inventory has 281 legacy receipts and zero full-family parity claims;
+the dynamic source ledger is conservative until each unit is explicitly mapped. Pending volume is
+concentrated in UI (3,930), Media I/O (585), Nodes (543), Mesh Editing (431), Rig
+Animation (375), Object Operations (316) and Simulation (155). Follow-up waves must
+select one source-backed family at a time, reuse existing receipts by hash, and require
+the same Main/Worker/frontend, negative, recovery and Chromium gates. The next
+checkpoint is the first explicitly authorized corrective or uncovered-family task after
+`WBV2-P1130-001`; do not infer full-family parity from representative slices.
+
 The asset-operator evidence through `M16-GAP-00281` is integrated into the generated
 completion registry. `M16-GAP-00282` remains the single legacy coverage checkpoint,
-while `WBV2-P0-002` is the current production task. The corrective pilots already
+while `WBV2/dynamic-inventory.json` is the current source-statistics artifact. The corrective pilots already
 provide reusable asset-catalog, modifier, mesh, history, and Chromium workflow
 primitives. New implementation work should extend those family primitives and add
 representative capability cases rather than adding another checker branch for each