[BUG] Orthogonal edge routing becomes incorrect after reconnecting an edge endpoint #1087

Description

When reconnecting the source or target terminal of an orthogonal edge, the generated route becomes inconsistent with the route shown during the reconnect preview.

The preview displays one orthogonal route, but after releasing the mouse button, the edge is rerouted and a different path is rendered.

Steps to Reproduce

1. Open the Orthogonal Storybook demo:
   https://maxgraph.github.io/maxGraph/demo/?path=/story/connections-orthogonal--default
2. Create a connection between two vertices.
3. Reconnect the target terminal to another vertex (or even reconnect it to the same vertex).
4. Observe the orthogonal route displayed during the reconnect preview.
5. Release the mouse button.
6. Observe that the final route differs from the preview route.

Expected behavior

The final route after reconnecting should match the route shown during the preview or match the route create by new connection.

Actual Behavior

Immediately after reconnecting a terminal, the orthogonal router may generate a different route than the one produced after reloading the graph.

Video:

Investigation:

While debugging, I found that the issue appears to occur during connection constraint resolution after a reconnect operation.

During reconnect operations, cleared connection constraints may be stored in the edge style as:

entryX = null
entryY = null

or

exitX = null
exitY = null

Graph#getConnectionConstraint() currently checks for undefined but not null:

const x = edge.style[source ? 'exitX' : 'entryX'];

if (x !== undefined) {
  const y = edge.style[source ? 'exitY' : 'entryY'];

  if (y !== undefined) {
    point = new Point(x, y);
  }
}

As a result, a ConnectionConstraint containing Point(null, null) can be created and later consumed by GraphView.updateFixedTerminalPoints().

This affects the generated absolutePoints and ultimately changes the orthogonal route.

From my investigation, this behavior became reproducible after commit 8504de2 (fix: correctly update style when calling Graph methods, #380).

My understanding is that the commit itself is likely not the root cause. Instead, it appears to expose an existing issue by ensuring that style updates correctly trigger StyleChange events. Once the style change is processed, the corresponding cell state is marked with invalidStyle = true and rebuilt from the cell style. At that point, style entries such as entryX = null or exitX = null are copied into the state and later interpreted as valid connection constraint coordinates because the constraint resolution logic only checks for undefined.