Phase 5 Stage C continued: wall, door, window now in registry floor plan

Three remaining kinds at Stage C this session:

wall → C
 - buildWallFloorplan: uses ctx.siblings to gather other walls in the
   level, runs calculateLevelMiters, computes plan footprint via
   getWallPlanFootprint. Same visual output as legacy.
 - getFloorplanWall thickness exaggeration inlined (~25 lines from
   editor/lib/floorplan/walls.ts) to keep nodes/wall self-contained.
 - floorplan-panel.tsx's wallPolygons short-circuits to [] when wall
   is registered.
 - Performance note: recomputes level miter data per wall (O(N²) for N
   walls in a level). Acceptable for typical scenes; ctx.levelData?.
   miters optimization deferred to Stage B's wall design pass.

door → C
 - buildDoorFloorplan: inlines getOpeningFootprint math from
   floorplan-panel.tsx (40 lines, pure math). Uses ctx.parent as the
   wall to compute direction + perpendicular for the cutout footprint.
 - Returns null when parent isn't a wall (orphaned doors during
   placement).

window → C
 - buildWindowFloorplan: same shape as door, glass-blue tint to
   distinguish visually.

Both share the legacy openingsPolygons gating:
 - floorplan-panel.tsx's openingsPolygons useMemo filters per kind so
   a partial migration still works (e.g., if only door registers, only
   doors get skipped). When both registered, returns [] entirely.

Item C intentionally deferred — needs parent-chain transform helpers
(buildFloorplanItemEntry / getItemFloorplanTransform from editor/lib/
floorplan/items.ts) exposed publicly or moved into core. A focused
session is the right place to design that boundary.

Stage B for door / window / wall still pending — each is a focused
session per kind (large geometry math extractions, wall needs ctx.
levelData design).

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

packages/nodes/src/door/definition.ts

@@ -1,4 +1,5 @@
 import type { NodeDefinition } from '@pascal-app/core'
+import { buildDoorFloorplan } from './floorplan'
 import { doorParametrics } from './parametrics'
 import { DoorNode } from './schema'
 
@@ -12,16 +13,14 @@ import { DoorNode } from './schema'
  *    keeps legacy `MoveDoorTool`.
  *  - `selectable`, `duplicable`, `deletable` standard.
  *
- * Relations:
- *  - `parentId` references a wall — re-anchors on wall move (handled by
- *    `DoorSystem`'s cascade to parent wall).
- *  - `cascadeDelete: 'children'` — door has no children in v1.
- *
- * Renderer + system: wrap-export legacy `DoorRenderer` + bundle
- * `DoorSystem` + `DoorAnimationSystem`.
- *
- * Tool field absent: door placement / move tools wired through editor
- * state, not registry dispatch. Legacy DoorTool / MoveDoorTool continue.
+ * Stages:
+ *  - A: registered.
+ *  - B: deferred — door geometry (frame / leaf / glass / hardware /
+ *    segments) is ~800 lines in DoorSystem; extraction is a focused
+ *    session. `def.renderer` (wrap-export of legacy DoorRenderer) +
+ *    `def.system` (DoorSystem + DoorAnimationSystem bundle) hold parity.
+ *  - C: `def.floorplan` polygon sits in parent wall's cutout. Legacy
+ *    `openingPolygons` short-circuits door entries when registered.
  */
 export const doorDefinition: NodeDefinition<typeof DoorNode> = {
   kind: 'door',
@@ -56,6 +55,9 @@ export const doorDefinition: NodeDefinition<typeof DoorNode> = {
     // before wall mitering at 4).
     priority: 3,
   },
+  // Stage C: floor-plan polygon. Needs ctx.parent (the wall) to compute
+  // direction + perpendicular for the cutout footprint.
+  floorplan: buildDoorFloorplan,
 
   toolHints: [
     { key: 'Left click', label: 'Place door on wall' },