fix(web): anchor the dashboard viewport across graph re-layout

[Jason Robert (jrob5756)]

Closes#375

The bug

layoutTopLevel normalizes each rebuild's bounding box to origin:

node.position={x: node.position.x-minX,y: node.position.y-minY};

When an expanded container grows, minX/minY shift, so every node in the
graph gets a new position — including nodes nowhere near the one that was
toggled. Meanwhile the camera is never touched: the fitView prop is
initial-render only (I confirmed in the React Flow source that fitViewQueued
is diff-guarded and cleared after the first successful fit), and
FitViewOnContextSwitch fires only on viewPathKey change.

So the entire world slides under a fixed camera. Visually that reads as "the
view reset", and after an expand/collapse round trip you're looking at the right
layout from the wrong place.

The fix

Leave the layout pass alone; compensate the camera instead. After each rebuild:

1. Pick an anchor node present in both the old and new node arrays.
2. Compute its canvas-absolute top-left in both layouts. This has to walk
   parentId chains — React Flow stores a nested node's position relative to
   its parent, and inline expansion re-parents nodes, so raw positions aren't
   comparable across a rebuild.
3. Pan by the negation of the delta, at unchanged zoom, with no animation.
4. Fall back to doing nothing when the two layouts share no node (first build,
   context switch), where the existing fitView paths still own the camera.

Anchor preference:

• The container owning the single expansion key that just toggled, so the
  chevron stays under the cursor. Both key namespaces sharing expandedContexts
  are checked (childContextKey for subworkflows/iterations,
  groupExpansionKey for for_each groups), on both sides of the rebuild —
  a group only carries groupExpansionKey once it's expandable.
• Otherwise the shared node nearest the pane center, tie-broken on node id.

Expand-all toggles many keys at once, so it takes the second branch. There's no
new exclusivity rule and no fitView on expansion — expand-all and N-at-once
keep working exactly as before.

The same compensation steadies the graph when a running workflow's topology
grows (a for_each fanning out, a subworkflow's DAG arriving), which today also
slides the graph under a fixed camera.

Structural note

WorkflowGraph gains a ReactFlowProvider wrapper. There was previously no
provider anywhere in the app — every useReactFlow() call site was a child of
<ReactFlow> and relied on its implicit provider. The rebuild effect lives
outside <ReactFlow> and so couldn't reach setViewport. Provider and
<ReactFlow> mount together (ResizableLayout swaps the whole graph out for
DialogOverlay), so the hoisted store has the same lifetime as before and the
initial fitView still runs once per mount. The export surface is unchanged.

Changes

• newweb/frontend/src/lib/graph-anchor.ts — pure: toAbsolutePositions,
  resolveAnchorId, anchoredViewport, nextAnchorHint. No React, no
  @xyflow/react runtime import, same shape as lib/reconnect.ts.
• newweb/frontend/src/lib/graph-anchor.test.ts — 35 tests.
• web/frontend/src/components/graph/WorkflowGraph.tsx — provider split plus
  the anchoring effect. No change to graph-layout.ts, the store, node
  components, or the event pipeline.
• CHANGELOG.md, rebuilt web/static/.

Verification

tsc -b clean; 98/98 frontend tests pass (35 new).

Browser-tested with Playwright against a live dashboard (1600x1000) running a
provider-free workflow with three subworkflow steps:

scenario	toggled node on-screen movement
expand subA	0.00 px
collapse subA	0.00 px
expand subA, then subB, then subC	0.00 px each

• expand → collapse returns to the byte-identical viewport transform string
• expand-all → collapse-all returns to the byte-identical transform
• all three subworkflows expand simultaneously (8 → 23 nodes)
• F, the Controls buttons (zoom in/out/fit), double-click drill-down and
  breadcrumb-back all still work
• no new console errors

Known limitation

Expanding three subworkflows individually and then clicking collapse-all
leaves ~19 px of horizontal pan, accumulating per repeat of that specific mixed
cycle. I traced it rather than guessing: three individual expands pin three
different containers, and no node in the collapsed layout carries the summed
delta needed to invert them, so it's structural rather than an anchor-selection
bug. Pinning one canonical node throughout would remove it, at the cost of the
property this exists for. Fit-view clears it, and it takes roughly 35 cycles
before content starts clipping. Documented in the module docstring.

Out of scope

• Preserving manual node drags across a rebuild. nodesDraggable is on but the
  rebuild replaces the node array wholesale, so a dragged node snaps back to its
  dagre position. Separate fix (position memoization keyed by node id).
• Animating the re-layout — much larger, and unnecessary once the camera stops
  jumping.