fix(canvas): stop infinite re-render on ContextMenu mount

[HongmingWang-Rabbit]

Summary

ContextMenu selector returned a new filtered array on every render → Zustand's `useSyncExternalStore` saw "snapshot changed" every tick → React scheduler hit the 50-update depth cap → crashes with minified error #185 ("Maximum update depth exceeded").

Visible as "Application error: a client-side exception" on every SaaS tenant once a session cookie resolved. My hongmingwang tenant hit this reliably today.

Root cause

```tsx
// ContextMenu.tsx before:
const children = useCanvasStore((s) =>
contextNodeId ? s.nodes.filter((n) => n.data.parentId === contextNodeId) : []
);
```

`filter()` returns a new array. `useSyncExternalStore` uses `Object.is` to compare snapshots — new arrays always fail that. Store → render → selector → new array → store hook thinks it changed → render again → infinite loop.

Fix

```tsx
// after:
const nodes = useCanvasStore((s) => s.nodes);
const children = useMemo(
() => (contextNodeId ? nodes.filter((n) => n.data.parentId === contextNodeId) : []),
[nodes, contextNodeId],
);
```

`nodes` reference is stable across unrelated store updates (Zustand only changes it when nodes themselves change). `useMemo` derives children without going through Zustand's subscription.

Same pattern to keep in mind elsewhere: never do `.filter` / `.map` / `.slice` / `{...}` inside a Zustand selector unless using `useShallow` or returning a primitive. `ProvisioningTimeout.tsx:39` uses the string-serialize trick for the same reason; worth a codebase-wide audit as follow-up.

Verification

• Served dev bundle through cloudflared tunnel to the live hongmingwang tenant
• Dev build surfaced the exact warning `The result of getSnapshot should be cached to avoid an infinite loop at ContextMenu.tsx:26:34` — pinpointed in 30 sec (vs hours of blind debugging on minified prod bundle)
• After fix: React error fix(security): gate GET /approvals/pending behind AdminAuth (#180) #185 gone; canvas renders; only remaining console errors are expected localhost API 401s from dev server topology

Not in scope

• Broader Zustand selector audit — separate issue
• Production source-map enablement (would have caught this without the dev-tunnel workaround) — separate ops task

🤖 Generated with Claude Code