[DO NOT MERGE] Consistent neighbor-feasibility soft veto for resizer moves — CI QoR eval

[mguthaus]

Goal

Make the resizer setup-repair moves evaluate their effect on neighboring
gates consistently. Today each move judges accept/reject differently, and the
"will this hurt a neighbor?" (neighborhood-feasibility) question is checked
unevenly — some moves account for it, some partially, some not at all. This PR
equalizes that across moves.

What was / wasn't checked before

Each move predicts a gain on the critical path, but the cost it imposes on
neighbors was handled ad-hoc:

Move	Neighbor cost considered before
sizeUp / vtSwap	Only the on-path fanin stage (via the DelayEstimator window). The larger cell raises input-pin cap on every fanin net, slowing all its fanin drivers — the off-path ones were never checked.
swapPins	The output-arc gain minus the critical input net's driver-delay change. The other swapped net's driver — which now sees a different pin cap — was not checked.
clone	Only the driver's load relief. The extra load the cloned input pins place on the fanin nets (the clone duplicates them) was not counted.
splitLoad	Only the driver relief. The moved (non-critical) loads, now behind the inserted buffer and taking its delay, were not checked.
sizeDownFanout	Did check the shrunk gate's own path against its slack budget — but via a bespoke, absolute check unique to this move, not shared with the others.

So the "do no harm to neighbors" criterion was inconsistent: different moves,
different (or missing) checks, different thresholds.

First attempt — a hard neighborhood-feasibility veto — was poor

We first tried the obvious thing: reject a move if any perturbed neighbor's
slack would drop below the slack of the endpoint being repaired. This behaved
badly:

• The on-path stage sits at the repair floor, so a move self-vetoes.
• Even excluding that, in a near-critical design almost every useful move nudges
  some near-critical sibling below the floor — so the veto blocks exactly the
  moves that drive closure. QoR collapsed (e.g. asap7/aes −0.70 → ~−9 ns), and
  no tolerance had a useful operating point: it only stopped hurting once it had
  effectively become a no-op.

The lesson: repair legitimately worsens a neighbor temporarily and fixes it on
a later pass. A hard "never worsen any neighbor" rule is fundamentally at odds
with how the repair loop works.

Solution — a soft veto (scale-free ratio, negative-slack only)

Replace the hard veto with a soft one that answers "did we give up more than we
gained?":

• gain = the move's predicted improvement to the critical path.
• harm, per neighbor = only the slack driven below zero:
  max(0, delay_delta − max(0, slack_before)). A neighbor with slack to spare
  absorbs the added delay for free and costs nothing.
• Reject only when the worst neighbor's negative-slack harm exceeds a
  ratio of the gain (default 0.3). Using a ratio makes it scale-free —
  no absolute, per-design/per-tech threshold to tune.
• All inputs are snapshotted in the generator, so the estimate stays free of
  live STA (MT-safe).

Now wired uniformly into sizeUp, vtSwap, clone, swapPins, sizeDownFanout, and
splitLoad. (buffer/Rebuffer is the remaining hold-out.) As part of this,
sizeDownFanout is migrated to the shared accept rule and enabled in the default
LEGACY sequence.

Early QoR (LEGACY, ratio 0.3)

• asap7/aes: −0.70/−0.70 → 0.00/0.00 (closes; slightly smaller area)
• asap7/ethmac_lvt: −23.71/−360 → −15.87/−219
• sky130hd/aes, jpeg: still slightly below their pre-feasibility baseline — a
  per-tech or annealed ratio is future work.

DO NOT MERGE

This bumps the OpenROAD submodule to an evaluation fork branch
(VLSIDA/OpenROAD move-eval-shared) purely so CI can assess QoR. Not intended
to merge.

[gemini-code-assist]

Code Review

This pull request updates the OpenROAD subproject commit in the tools directory to 6deec3bc574ef78b2d6d3356c01576119bbacb22. There are no review comments, and I have no feedback to provide.

[maliberty]

The extra load the cloned input pins place on the fanin nets (the clone duplicates them) was not counted.

I don't follow as cloning just replaces one pin with another equivalent one. I don't see where extra load is generated.

[mguthaus]

The other inputs now need to drive both cloned gates. Let's say you have a gate Z=NAND(A,B), and you clone it because Z has multiple fanout, some of which are critical. "A" might be the critical input that gets checked today but B also gets more load because of the fan out and isn't checked. It could become critical.

I'm still playing with this code so no need to review right now.