Cap duplicate ports by physical boundary capacity

[ShiboSoftwareDev]

Root cause

DuplicateCongestedPortSolver treated duplicatePortProximity as an unlimited pool of extra graph ports. It did not use the shared boundary's physical length, trace width, or clearance, so seven different routes could be assigned only 0.007 mm apart.

Fix

When physical spacing is supplied, the solver now:

1. finds the shared axis-aligned boundary for the two regions;
2. computes how many trace centers fit using trace width and minimum spacing;
3. creates only that many lanes and spaces them legally along the boundary.

Excess routes remain for the hypergraph solver to send through another opening or layer. No invalid geometry fallback is added.

Same fixture, before and after

Before: graph overstates capacity	After: graph matches physical capacity

Blue rectangles are the graph regions, red is the physical trace width, orange is the required pitch, and black dots are port centers.

Validation

• bun test tests/solver/duplicate-congested-port-physical-capacity-repro.test.ts
• bun test tests/solver/duplicate-congested-port-physical-capacity.test.ts
• bun test tests/solver/duplicate-congested-port-solver.test.ts
• Downstream srj24 sample 4 completes Pipeline7 port-point pathing at the normal 1× / 2,000,000-step budget when this commit is linked.

Stacked on the reproduction PR.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
tiny-hypergraph	Ready	Preview	Aug 2, 2026 4:30am

[tscircuitbot]

Benchmark This PR

Run benchmarks by commenting on this PR:

/benchmark [benchmark.sh args...]
/benchmark --dataset <hg07|srj18> --limit <n> --solver <core|poly> --families <default|default+deep|all> --concurrency <n|auto>

Everything after /benchmark is forwarded directly to ./benchmark.sh.
The result comment shows the matching dataset from the latest stored main-branch benchmark artifact beside the PR run; main is not rerun for each PR benchmark request.

Examples:

• /benchmark -> hg07, all samples, core solver
• /benchmark --dataset srj18 --limit 20 -> first 20 srj18 samples
• /benchmark --dataset srj18 --concurrency auto -> srj18 samples with runner CPU-count concurrency
• /benchmark --sample sample002 -> one hg07 sample
• /benchmark --limit 20 --solver poly -> first 20 hg07 samples with the poly solver
• /benchmark --limit 40 --families default+deep -> first 40 hg07 samples with deeper candidate families

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