Wall Phase 3 milestone A: registry skeleton (metadata only)

Lays down the wall folder under @pascal-app/nodes with everything needed
to register the kind, but intentionally without runtime wiring:

- schema.ts re-exports WallNode from core (door/window/item still type
  their parentId against WallNode.shape.id, so the schema stays canonical
  there for now).
- parametrics.ts declares thickness / height / curveOffset for the Phase 4
  inspector. Endpoints and host children are edited via affordances, not
  number inputs, so they're not in parametrics.
- definition.ts encodes capabilities (surfaces, selectable, duplicable,
  deletable — no movable since wall's move is bespoke endpoint-drag),
  relations (hosts doors/windows/items, affectsSpatial slabs/ceilings/
  zones, linkedBy endpoint-match, cascadeDelete descendants), and the
  presentation metadata for the palette. Renderer / system / tool fields
  are deliberately absent — the existing wall-renderer.tsx and
  wall-system.tsx keep serving wall until milestone B.
- feature-flag.ts gates the eventual registration via
  NEXT_PUBLIC_USE_REGISTRY_FOR_WALL (same pattern Phase 2 used for spawn).
- wallDefinition is NOT yet appended to builtinPlugin.nodes — registration
  is what flips the Phase 0 dispatch shims, and we don't want that until
  the runtime port lands. Until then this file is metadata-only.

Two type-side changes pulled forward from Phase 4 to make a metadata-only
definition compile:

- NodeDefinition.renderer becomes optional (the three-checkbox model
  documented in wiki/architecture/node-definitions.md already promises
  this). RegistryRenderer in node-renderer.tsx gains a null-guard so an
  undefined renderer cleanly falls through to the legacy switch.

No runtime behavior change. Walls render and behave exactly as before.

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

packages/nodes/src/wall/schema.ts

@@ -0,0 +1,12 @@
+/**
+ * Wall schema re-export.
+ *
+ * Wall's Zod schema lives in `@pascal-app/core` because doors, windows, and
+ * items still need to type-check their `parentId` against `WallNode.shape.id`
+ * before the migration to a `relations.hosts`-driven model is complete. The
+ * registry definition consumes it from here so the rest of the bundle
+ * imports a single canonical type.
+ */
+
+export type { WallNode as WallNodeType } from '@pascal-app/core'
+export { WallNode } from '@pascal-app/core'