Recover net labels that don't fit at their configured size

[Priyanshubhartistm]

Summary

• NetLabelPlacementSolver was silently dropping a net label group when a caller-specified netLabelWidth/netLabelHeight didn't fit anywhere near a cramped pin bracket (found via repro-atmega328p-missing-gnd-netlabel, where a netLabelHeight: 0.42 GND label had nowhere to go near U_MCU.3/U_MCU.5).
• Added a size fallback tier: retry at the default label size, first at the caller's declared orientation, then any orientation only if that's still too tight.
• Same silent-drop bug was already hiding in 7 other fixtures - this fix recovers all of them except one already-unrelated RP2040 case.
• Replaced the atmega328p repro's snapshot-only test with a real assertion that the GND label exists.

Validation

• bun run format:check
• bunx tsc --noEmit
• bun test (180 pass, 4 pre-existing skips, 0 fail)
• Compared failedGroups/netLabelPlacements counts before vs. after across all 8 affected fixtures to confirm the change only turns failures into successes, never touches an existing placement

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
schematic-trace-solver	Ready	Preview	Aug 20, 2026 9:29pm

[mohan-bee]

i see some bad regression

[Priyanshubhartistm]

@mohan-bee right - recovering the GND label pushes VCC_3V3 into a spot that overlaps another label. Root cause is that label placement never checks against other already-placed labels, just chips/traces/text. Real fix for that touches ~21 other snapshots, so it's too big for this PR - will handle it separately.

[mohan-bee]

@mohan-bee right - recovering the GND label pushes VCC_3V3 into a spot that overlaps another label. Root cause is that label placement never checks against other already-placed labels, just chips/traces/text. Real fix for that touches ~21 other snapshots, so it's too big for this PR - will handle it separately.

tbh that regression is so bad