fix(topology): detect BGA cores in mixed packages

[ShiboSoftwareDev]

Stack

Stacked on reproduction PR #1798. Review that test-only PR first.

Root cause

srj24 sample 4 contains a regular 13×13 BGA core inside a 337-pad mixed package. The existing detector evaluated all pads as one component, so the mixed pad geometry hid the core. Component-topology ownership also used only componentId, which would absorb unrelated perimeter pads if a partial core were detected.

What changed

This implements the first two topology fixes without adding a pipeline stage:

1. reuse BGA geometry rules to select the largest complete, uniformly pitched, same-geometry grid inside a mixed component;
2. use that detected grid's bounds when replacing and serializing component obstacles, leaving perimeter pads in the global topology.

There are no route-specific IDs, dataset thresholds, pathing heuristics, target-layer promotion, or iteration-budget changes.

Before/after visualization

The fixture includes differently shaped perimeter pads and irregular same-size pads, matching the property that made the real sample difficult. The final frame is computed from the real merged/subdivided capacity graph and shows a legal z0 → multilayer BGA gap → z5 path.

Real-sample verification and scope boundary

At effort 1, a fresh srj24 sample 4 run completes Pipeline7 stages 1–10 with this change, including component detection, topology planning/merging, subdivision, edge construction, and necessary cramped-port preparation. The original static reachability error for source_trace_94__source_net_94_mst1 is gone.

Current main then reaches a separate path-search limit:

SelectiveReripTinyHyperGraphSolverWithStableInitialAssignments ran out of iterations at 2,000,001 iterations.

Therefore this PR establishes the legal topology required to fix sample 4 but does not claim that the current-main pathing solver completes the full sample by itself. As a compatibility check, the previously known pathing implementation completed the same sample after the topology was legal (2,000,004 iterations, about 412.7 seconds).

Checks

• bun test tests/component-detection-bga-only.test.ts tests/features/topology/srj24-sample4-topology-repro.test.ts tests/features/topology/srj24-sample4-topology-fix.test.ts --timeout 9999999 — 17 passed
• bun test tests/features/topology/topology-merging tests/features/topology/merged-topology tests/features/topology/bga-topology --timeout 9999999 — 17 passed
• bun run build
• bun scripts/run-sample.ts --pipeline 7 --sample 4 --dataset srj24 --out-dir /private/tmp/srj24-clean-final-topology-proof --stop-after-stage necessaryCrampedPortPointSolver --effort 1

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
capacity-node-autorouter	Ready	Preview	Jul 31, 2026 5:20am

[tscircuitbot]

Benchmark This PR

Run benchmarks by commenting on this PR:

/benchmark [benchmark.sh args...]
/benchmark-long [benchmark.sh args...]
/benchmark-all

Comment /benchmark to run the default dataset, or append any arguments accepted by ./benchmark.sh.
Comment /benchmark-long for an 8-vCPU run that defaults to 8 workers and has an eight-hour timeout.
Comment exactly /benchmark-all to start separate workflow runs and result comments for the default dataset plus srj18, srj19, srj20, srj21, and srj23.

Everything after /benchmark or /benchmark-long is safely forwarded to ./benchmark.sh, except --profile-solvers, which enables profile comparison tables.
Examples: /benchmark --dataset 18 --sample-timeout 2000s, /benchmark --pipeline 7 --scenario-limit 20, /benchmark all 20 --concurrency 8, and /benchmark-long --dataset 18.

Use /update-snapshots (or /us) to run BUN_UPDATE_SNAPSHOTS=1 bun test --timeout 120_000 on the PR branch and auto-commit snapshot updates.
Use /usf to read recent failed test files, update and verify their exact CI test shards, and auto-commit only their snapshots. It uses the configured fast benchmark runner by default; use /usf --ubuntu-latest for GitHub-hosted x64 CI parity.

Any PR whose title contains [BENCHMARK TEST] will automatically run one default-dataset benchmark on PR updates; it does not post a PR result comment.