Fix order-dependent port renaming; close gdstk backend gaps

[carloscl03]

Two commits. The first is a real bug in port_utils that affects the default
backend too; the second unblocks GLAYOUT_BACKEND=gdstk for the opamp.

Renaming ports depends on dict order

rename_component_ports renames in place — pops the old key and inserts the
new one on the same dict it just iterated:

for namepair in names_to_modify:
    if namepair[0] in custom_comp.ports.keys():
        portobj = custom_comp.ports.pop(namepair[0])
        custom_comp.ports[namepair[1]] = portobj

When a port renames onto a name another port still holds, that guard silently
skips it and one of the two is dropped. Which one survives depends on insertion
order.

rename_ports_by_orientation triggers this routinely: a mirrored port has
orientation 90 and legitimately renames _S -> _N onto a name still queued.
In diff_pair(gf180, width=3, fingers=4) that is 334 ports.

Same component, same port, orientation 90.0:

backend	result
gdsfactory	keeps bl_multiplier_0_source_S (90° is N, so this is wrong)
gdstk	gives bl_multiplier_0_source_N (correct)

add_df_labels then raises KeyError on the latter. It works under gdsfactory
by accident of ordering, not by construction.

Fix builds the renamed mapping first, then swaps it in.

diff_pair(gf180, width=3, fingers=4)
  before   4530 ports    gdstk: KeyError 'bl_multiplier_0_source_S'
  after    4864 ports    both backends identical

The 334 extra ports are the ones that were being dropped.

gdstk backend gaps

With the rename fixed, the opamp got further and hit four more gaps, found one
at a time:

1. Component.add() rejected a bare Component. gdsfactory accepts one and
   references it implicitly; several composite cells rely on that.
2. diff_pair_stackedcmirror imported rectangle straight from gdsfactory,
   bypassing the backend abstraction — the module already imports the backend's
   rectangle at module level.
3. ComponentReference.info held its own empty dict. mimcap_array writes
   info['netlist'] on the Component while opamp_twostage reads it back off
   the reference returned by <<; gdsfactory exposes the parent's info through
   the reference, so delegate.
4. Component.ref() took no arguments. opamp.py:155 calls
   ref(position=...).

Results

opamp(gf180, ...), same parameters as GLayout_Cells.ipynb cell 14:

backend	time	ports
gdsfactory	383.0 s	—
gdstk	55.5 s	99090

No regression: under gdsfactory, nmos(gf180, width=3, fingers=4) produces
3328 ports and 875 polygons before and after.

Note

This makes the fast backend usable; it does not address why the slow one is
slow. Profiling the opamp under gdsfactory shows 96% of runtime inside
pydantic validation, 6.3M serialization.py calls, and 1.85M Port objects
created — 93% of a transistor's ports belong to individual vias that are never
routed to. That is a port-model question, not something a compatibility fix
reaches.

[carloscl03]

Context on why this came up: #100's notebook check fails on
GLayout_Cells.ipynb, and main fails the same way — the opamp cell crosses
--cell-timeout 180 on slower runners (87 s on the runner that passed, so
roughly a 2x swing is enough to trip it).

Chasing that led here. With GLAYOUT_BACKEND=gdstk the same cell drops from
383 s to 55.5 s, which would take that check well clear of the limit rather
than leaving it near the edge. The gdstk backend could not build the opamp at
all before these fixes, so that number was not measurable until now.

So this does not fix #100's check directly, but it makes switching the notebook
job to the fast backend a viable option — likely more durable than raising the
timeout, since the current margin depends on which runner GitHub hands out.