fix: reject net-label candidates whose connector runs along another net

[DPS0340]

Stacked on #719 — that should merge first. This adds a second predicate to the same check.

Problem

#719 rejects net-label candidates whose connector crosses another net. But crossing isn't the only way a connector misleads: one laid along another net's trace renders as a single wire carrying two nets. The crossing predicate can't catch it, because collinear segments never intersect at a point.

Exactly one instance in the corpus, on bug-report-20260707T092615Z:

V overlap, length 0.141
  A  C_SENSE.2-C1.2                        net=connectivity_net1   (-9.809,-1.705)→(-9.809,-1.905)
  B  available-net-orientation-13-BAT_POS  net=connectivity_net13  (-9.809,-2.915)→(-9.809,-1.764)

Same x, overlapping y ranges, different nets — drawn as one wire.

Fix

segmentsOverlapCollinearly in geometry.ts, and a rejection in getCandidateStatus sitting directly beside the crossing rejection #719 adds. Reuses the existing trace-collision status, so no new candidate state.

The predicate requires a shared length, not a shared point: touching at one point is a crossing or a junction, both of which are legitimate and handled elsewhere.

Result

different-net collinear overlaps:  1 -> 0

Everything else holds steady:

trace crossings:      19 -> 19   (as left by #719)
labels inside chips:   8 ->  8
label-label overlaps:  7 ->  7
diagonal segments:     2 ->  2

Verification

• Full suite 168 pass / 0 fail / 4 skip, tsc --noEmit clean, biome clean.
• 2 snapshots regenerated.
• repro-atmega328p-missing-gnd-netlabel is one of them, and the name is alarming, so I checked it rather than accepting the regeneration. That test only asserts a snapshot, no behaviour. Comparing label output against main:

  main:     18 labels — GND, VCC_3V3, X_IN1, X_IN2, Y_IN1, Y_IN2, …
  this PR:  18 labels — GND, VCC_3V3, X_IN1, X_IN2, Y_IN1, Y_IN2, …
  

  Identical count and identical net list, GND included. The labels moved, none were lost — the property that repro exists to protect is intact.

Diff: 2 source files plus the 2 snapshots.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
schematic-trace-solver	Ready	Preview, Comment	Jul 26, 2026 3:58am

[DPS0340]

Moved to draft — this PR regresses #727, which merged a few hours ago. Reporting it against myself rather than letting it sit as ready.

After rebasing onto current main, repro-rp2040-usb-cc2-ground-overlap fails:

expect(cc2LabelConnector).toBeDefined()
Received: undefined

The collinear-overlap predicate this PR adds rejects every candidate orientation for the CC2 label, so no connector is generated at all. #727 fixed that board by shifting the overlapping trace; my check instead removes the label connector, which is worse than the original bug.

Crossing counts, for completeness:

main            TOTAL 41   (092615Z: 3)
+ #718 #719     TOTAL 20   (092615Z: 3)
+ #723 (this)   TOTAL 19   (092615Z: 2)

So it does buy one more crossing and improves 092615Z back to its pre-#727 value — but not at the cost of dropping a connector.

#719 is unaffected and stays ready. It is rebased onto current main, 167 tests pass, and it does not touch the collinear predicate.

I'll rework this one to fall back to the best available orientation instead of rejecting outright when no overlap-free candidate exists, then re-measure against #727's test. Not asking for review until that passes.

[DPS0340]

Reworked as described — the #727 regression is fixed and this is ready again.

The problem was that the collinear-overlap check rejected every candidate orientation for the RP2040 CC2 label, so no connector was emitted at all. Leaving a label unattached is worse than an overlap the cleanup passes can still shift, so the rejection is now a preference rather than a veto:

try for an overlap-free orientation
  ↓ none found
take the best available one anyway

Same shape as the existing crossing check.

Verification:

	before	after
repro-rp2040-usb-cc2-ground-overlap	cc2LabelConnector undefined	✅ pass
full suite	165 pass / 2 fail	167 pass / 0 fail
different-net crossings	TOTAL 19	TOTAL 20

The total goes from 19 back to 20 — that one crossing was bought by dropping a connector, so it was never a real gain. Still an improvement on the 41 that current main measures.

I also checked the fallback isn't dead code: instrumented it across all imported bug reports and it fires 28 times, so it is load-bearing, not defensive.

Stacked on #719, which is unaffected and already ready.