Extract the boundaryProxyView module

[CuriouslyCory]

What to build

The boundary proxy is a load-bearing domain concept (ADR-0031 / ADR-0036), but its view-side rules are smeared across the 2750-line canvas island: coalescing per-edge proxy rows that share a realEndpointId into one rendered node, rail placement / railPosition, the repOnScope endpoint→on-scope-representative mapping, and survivingProxies (which proxies remain when a set of Connections is removed). One copy of the re-add logic is already extracted (readdCrossScope) but only the undo path uses it.

Lift these pure functions into one boundaryProxyView module with a small interface (roughly layout(proxies, edges), survivingProxies(proxies, retainedEdgeIds), repOnScope(...)) and unit tests. Route the canvas's proxy layout (placement + coalescing) through it. Routing the delete/undo/connect paths through survivingProxies is a separate slice — this slice establishes the module and uses it for layout.

Keep these as pure, DOM-free functions so they can be unit-tested off-screen. Do not change rendered behavior; this is an extraction.

Source: architecture review, candidate 02a.

Acceptance criteria

• A boundaryProxyView module exists exposing the proxy layout, coalescing, repOnScope, and survivingProxies logic as pure functions
• The canvas computes proxy placement and per-realEndpointId coalescing via the module, not inline
• The module has unit tests covering coalescing, rail placement, and survivingProxies
• No change to rendered boundary-proxy behavior (placement, coalescing, drag-persist) — verified in the running app
• pnpm check and pnpm test pass

Blocked by

None - can start immediately