chore(core): evict runtime R3F from the core barrel + architecture test

[wass08]

What

Two moves that make the `@pascal-app/core` barrel safe to import from server code, plus a test that keeps it that way:

• `ElevatorRuntimeSystem` moves to `@pascal-app/nodes` (its only consumer). It was the last runtime `@react-three/fiber` import in core; `stepElevatorRuntimes` stays exported from core, so the nodes package now owns the 10-line `useFrame` wrapper.
• `useRegistryVersion` export moves from `registry/index.ts` to the core barrel. The registry barrel is reachable from server-safe graphs (schema → spatial grid → registry), and its `react` import crashed Next.js route handlers importing `@pascal-app/core/schema` (found by private-editor's capture-converter server-safety guard against this branch's dist). Public API unchanged — consumers already import the hook from `@pascal-app/core`.
• New `packages/core/src/architecture.test.ts`: fails core on any runtime `three`/`@react-three/*` import (whole-clause `import type` is erased and allowed). Runs in core's normal `bun test src`, so it gates both this repo and private-editor CI.

Red/green proof

The architecture test was proven red on a probe file exercising all three runtime forms — named import (`import { useFrame } from '@react-three/fiber'`), side-effect import (`import 'three/…'`), and mixed type/value (`import { type Object3D, Group } from 'three'`) — each individually reported, then green on the cleaned tree. Before the elevator move it also flagged the real `elevator-runtime-system.tsx` violation.

Why

Layer rule (AGENTS.md): core is pure logic, no Three.js. A runtime R3F import in the barrel evaluates React client context in every consumer, which 500s Next.js route handlers under the RSC server condition (the capture-upload outage class). Part of the regression-testing program's cheap-invariants slice.

🤖 Generated with Claude Code

---

Note

^{Cursor Bugbot is generating a summary for commit cab7f9a. Configure here.}