Validate copper added by safe layer moves

[seveibar]

Safe layer moves could reduce the total DRC count while adding a wire or via annulus over foreign copper, or placing an interior-span via inside a pad. Validate newly added copper before committing the move. Existing copper may retain incoming violations, including terminal segments shortened by the layer move.

The operation checks canonical net aliases, physical endpoint widths, via layer spans, fixed routes, plated through-obstacle bodies, and rotated rectangular or rounded pads. New outside-pad vias preserve explicit pad clearance; same-net pads retain annulus non-overlap when no spacing is declared. Explicit via-in-pad operations keep their separate behavior. Search limits and the DRC evaluator are unchanged.

Retained copper is recognized by exact primitive keys or endpoint-disc containment within an original capsule. The containment calculation accounts for floating-point roundoff using coordinate magnitude; it does not add a PCB clearance tolerance. New extensions, thicker copper, and displaced contacts remain rejected.

Validation: 113 native tests / 4,030 assertions and TypeScript pass. Generic regressions cover foreign wire/via contacts, thick endpoint caps, plated bodies, translated interior-pad contacts, layer membership, same-net aliases, declared clearance, and split terminal copper at multiple rotations and translations. Native and Linux sample 9 remain DRC clean; the reviewed pad-feasibility snapshot removes one prior same-net via/pad contact.

Two small performance changes avoid unnecessary work without changing candidate decisions: existing expanded pad bounds skip exact distance transforms for separated points, and topology-only candidates skip constructing a force-movement index they never read. Generic tests compare legal via positions and eager-versus-sparse candidate geometry and acceptance.

Full installed-package SRJ18 samples 4, 6, and 15 remain reference DRC clean with the retained-copper correction. Sample 4 final geometry and regional search work are unchanged from the prior implementation. Full profiled runs were affected by system load and interruptions, so they are not used as benchmark speed claims; the autorouter PR will report its unchanged same-machine benchmark separately. Prior mock-based replay timings are excluded from validation evidence.

Stacked on #115; no dependency merge is requested by this PR.

[tscircuitbot]

Benchmark This PR

Run benchmarks by commenting on this PR:

/benchmark [benchmark.sh args...]
/benchmark [scenario-limit|all] --dataset <drc14|srj18> --concurrency <n> --effort <n> --max-iterations <n>

Everything after /benchmark is forwarded directly to ./benchmark.sh.

Examples:

• /benchmark -> run default SRJ18 benchmark settings
• /benchmark 10 -> run first 10 SRJ18 samples
• /benchmark --dataset srj18 -> run all SRJ18 samples
• /benchmark 1 --dataset srj18 -> run the first SRJ18 sample
• /benchmark --dataset drc14 -> run all DRC14 samples
• /benchmark all --concurrency 4 -> run all SRJ18 samples with 4 workers
• /benchmark --scenario-limit all --effort 2 -> run all samples with effort 2
• /benchmark --scenario-limit 20 --max-iterations 100 -> run 20 samples with a max iteration override

Any PR whose title contains [BENCHMARK TEST] will automatically run the benchmark workflow on PR updates.