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 15, 2026 5:38pm

[seveibar]

tbh we're not really interested in improving any interactive features right now, there are generally much better solutions than what we have and we don't want to introduce any code related to the old system