Use obstacle offBoardConnectsTo groups when generating point pairs

[0hmX]

Parent: SRJ-23 remaining completion failures.

Problem

In sample 101, pcb_port_30 and pcb_port_32 both carry:

• offBoardConnectsTo: source_component_internal_connection_3
• netIsAssignable: true

However, NetToPointPairsSolver2_OffBoardConnection builds equivalence groups from connection-level isOffBoard data and does not consume obstacle-level offBoardConnectsTo. It therefore emits source_net_0_mst1 between those two off-board-equivalent pads. The generated pair is geometrically forced through net 4's pcb_port_31.

Acceptance criteria

• Point-pair generation recognizes obstacle-level off-board equivalence.
• It does not emit routes between points already connected by the same off-board group.
• Connectivity remains correct when an off-board group offers multiple candidate endpoints.
• Add a focused sample-101-style regression test.
• Keep visualization labels net-oriented where a point participates in multiple net aliases.

[DPS0340]

I prototyped the obvious version of this and hit a trap worth recording before someone else tries the same thing.

Confirmed diagnosis. NetToPointPairsSolver2_OffBoardConnection builds its DSU purely from connection-level isOffBoard; obstacle-level offBoardConnectsTo is never read. (getConnectivityMapFromSimpleRouteJson does consume it, so the two disagree.) A focused test with two pads sharing source_component_internal_connection_3 emits a redundant on-board pair on main.

The naive fix breaks connectivity. I unioned points sitting on obstacles that share an off-board id, and skipped pairs whose endpoints landed in the same DSU set. The new test passed, but tests/features/tracewidthsolver/example001 regressed. The reason is not cosmetic:

MAIN                                                    MINE
source_net_1_mst0  pcb_port_2  -> pcb_port_3   0.300    pcb_port_2 -> pcb_port_3   0.300
source_net_1_mst1  pcb_port_3  -> pcb_port_19  7.994    pcb_port_3 -> pcb_port_2   0.300   <-- reversed mst0
source_net_0_mst1  pcb_port_1  -> pcb_port_17 21.197    pcb_port_1 -> pcb_port_0   0.300   <-- reversed mst0
TOTAL                                         45.686                              17.095

The shorter total is an illusion. _findBestConnectionPointsFromDisjointSets rewrites each MST edge to the closest pair in the equivalence groups, so once the groups get wider, the second MST edge collapses onto the reverse of the first. pcb_port_19 and pcb_port_17 simply stop being reached — the MST edge that was carrying them is gone.

So the substitution step and the redundancy step can't both key off one widened DSU. Two directions that seem workable:

1. Keep off-board equivalence in a separate structure from the substitution DSU: use it only to drop pairs, never to pick substitutes.
2. Do the redundancy check on the MST before substitution, and make substitution preserve the set of endpoints the MST intended to reach (e.g. forbid a substitute already used by another edge in the same connection).

I'd lean toward (1) since it keeps the existing optimization untouched. Before I build it out — is that the shape you want, and should sample 101 grow a fixture here so the acceptance criteria are checkable? Happy to take it either way.