Wall Phase 3 milestone B: runtime port behind feature flag

Brings the wall kind onto the registry path when
NEXT_PUBLIC_USE_REGISTRY_FOR_WALL=true; default-off keeps wall on its
legacy path unchanged.

Files added:

- nodes/src/wall/renderer.tsx — thin placeholder-mesh mount point.
  Identical pattern to the legacy WallRenderer: registers ref via
  useRegistry, marks dirty on mount, renders hosted children
  recursively via NodeRenderer. The legacy WallSystem fills geometry
  on the next frame regardless of which mount path is active.

- nodes/src/wall/system.tsx — a bundle component that renders
  <WallSystem /> + <WallCutout /> (both re-exported from viewer).
  Registered via def.system with priority 4 to mirror the legacy
  WallSystem's useFrame priority. Zero logic duplication — the
  ~970 lines of CSG/mitering/cutaway code stays in viewer.

Files changed:

- packages/viewer/src/index.ts — new exports for WallSystem, WallCutout,
  and NodeRenderer. The first two so the registry-driven system bundle
  can compose them; NodeRenderer so any parent kind (wall, slab,
  ceiling, building) can recursively render hosted children without
  reaching into viewer internals.

- nodes/src/wall/definition.ts — adds renderer + system fields. Tool
  field stays absent (wall placement / endpoint drag remain bespoke
  for now; the affordance port is a later milestone).

- nodes/src/index.ts — conditionally appends wallDefinition to
  builtinPlugin.nodes based on isWallRegistryEnabled(). With the flag
  off, the array is identical to before this commit; with it on,
  Phase 0 dispatch shims switch wall to the registry path:
    * <LegacySystem kind="wall"> around WallSystem returns null
    * <LegacySystem kind="wall"> around WallCutout returns null
    * <NodeRenderer> takes the registry-first branch and mounts the
      new renderer instead of the legacy switch case for 'wall'
    * RegisteredSystems mounts the new system bundle, which re-mounts
      the same WallSystem + WallCutout components from viewer

No behavior change with the flag off. With the flag on, behavior should
be byte-identical (same components, same priority, same geometry path).
Manual verification next: place walls, t-junctions, walls-with-doors
with the flag toggled both ways; confirm visual + interactive parity.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

packages/nodes/src/index.ts

@@ -1,6 +1,7 @@
 import type { AnyNodeDefinition, Plugin } from '@pascal-app/core'
 import { shelfDefinition } from './shelf'
 import { spawnDefinition } from './spawn'
+import { isWallRegistryEnabled, wallDefinition } from './wall'
 
 /**
  * Built-in plugin bundling every node kind shipped with the Pascal editor.
@@ -18,15 +19,30 @@ import { spawnDefinition } from './spawn'
  * present in viewer/editor packages but short-circuited by the Phase 0
  * dispatch shims (`nodeRegistry.has('spawn')` is true → legacy path
  * yields). Legacy spawn files are deleted in a follow-up PR.
+ *
+ * Phase 3 status: wall is registry-driven *behind a feature flag*. With
+ * `NEXT_PUBLIC_USE_REGISTRY_FOR_WALL=true`, `wallDefinition` is included
+ * here and the Phase 0 shims switch wall to the registry path; the
+ * `<LegacySystem kind="wall">` wrappers around `WallSystem` and
+ * `WallCutout` short-circuit and the bundled `system.tsx` re-mounts them
+ * via `RegisteredSystems`. Off (default): wall stays on the legacy path.
+ * The flag drops the moment parity is signed off across the Phase 3
+ * fixture scenes — until then it gates the migration safely.
  */
+const wallEntries: AnyNodeDefinition[] = isWallRegistryEnabled()
+  ? [wallDefinition as unknown as AnyNodeDefinition]
+  : []
+
 export const builtinPlugin: Plugin = {
   id: 'pascal:core',
   apiVersion: 1,
   nodes: [
     shelfDefinition as unknown as AnyNodeDefinition,
     spawnDefinition as unknown as AnyNodeDefinition,
+    ...wallEntries,
   ],
 }
 
 export { shelfDefinition } from './shelf'
 export { spawnDefinition } from './spawn'
+export { wallDefinition } from './wall'