fix: restore trace-dash highlighting during component drag

[Priyanshubhartistm]

Summary

• useChangeSchematicTracesForMovedComponents was silently failing to dash traces during a component drag, for two separate reasons.
• A stale edit event (component removed from circuitJson) used return instead of continue, aborting every edit event after it in the queue — including the one actively being dragged.
• The schematic_trace → source_trace join used source_trace_id, which circuit-json now populates with a display label (e.g. "R1.2-C1.1") instead of a real id, so the join always returned zero traces. Switched to subcircuit_connectivity_map_key, matching useSchematicNetHover's existing approach.
• Extracted the logic into a pure getTraceIdsToDash() (lib/utils/get-trace-ids-to-dash.ts) so both fixes have real test coverage.
• Added examples/example32-stale-edit-event-trace-dash.fixture.tsx to reproduce the stale-event scenario in Cosmos.

Validation

• bun run format:check
• bunx tsc --noEmit
• bun test (8 pass, 0 fail)
• Verified visually with a real browser (Playwright): dragged a component and confirmed stroke-dasharray goes from "0" to "20,20" on the connected trace, mid-drag.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
schematic-viewer	Ready	Preview	Aug 12, 2026 8:42pm