Apply crystal trace limits through routing DRC

[seveibar]

Summary

• make Crystal own its default/configured maximum trace-length behavior
• apply the limit in Crystal.doInitialSourceDesignRuleChecks(), immediately after connectivity-map keys are generated
• constrain direct crystal traces plus MCU and load-capacitor branches on the same nets
• preserve stricter per-trace constraints, such as capacitor decoupling limits
• remove crystal-specific propagation from Group and generic Trace utilities
• remove the bespoke insertPcbTraceTooLongWarnings mutation path

Architecture

Core tees up Circuit JSON from the owning component: each crystal writes the effective constraint to matching source_trace.max_length records during the source DRC phase. The normal board runDrcChecks → runAllRoutingChecks pipeline then emits pcb_trace_too_long_warning elements through the generic check released from tscircuit/checks#174.

This PR now depends on the published @tscircuit/checks@0.0.146 release containing that generic check.

Validation

• focused crystal propagation and warning integration tests pass against published @tscircuit/checks@0.0.146
• configured crystal limits preserve stricter capacitor limits
• bunx tsc --noEmit
• GitHub Actions: all four Bun test shards, type-check, smoke-test, dependency check, and Vercel pass

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
tscircuit-core-benchmarks	Ready	Preview, Comment	Jul 24, 2026 7:07pm

[tscircuitbot]

---

Thank you for your contribution! 🎉

PR Rating: ⭐⭐⭐
Impact: Major

Track your contributions and see the leaderboard at: tscircuit Contribution Tracker

---