fet: allow narrow devices via dogbone diffusion

[carloscl03]

Problem

nmos/pmos raise ValueError below W=0.5 µm on gf180:

ValueError: via_array,size:dim#1=0.28 < 0.46

Forcing the width through produces 12 CO.4 violations (COMP overlap of contact).

The limit is in the generator, not the technology. The PDK's own pcell
(gf180mcu::nfet_03v3_draw) declares wmin=0.22 and lays out a 0.22 µm device
DRC-clean — its COMP has two different heights.

Root cause

The diffusion rectangle is sized with the channel width:

# fet.py
diff_dims = (diff_extra_enc + evaluate_bbox(multiplier)[0], width)

So a narrow channel drags the contact diffusion down with it, and the COMP no
longer encloses the contact by the 0.07 µm that CO.4 requires:

        COMP
   +---------------+
   |///////////////|  0.03 µm   <- CO.4 violation (0.07 required)
   +---------------+
   |   mcon 0.22   |
   +---------------+
   |///////////////|  0.03 µm   <- violation
   +---------------+

But electrical width is set by the poly over the channel, not by the
diffusion at the contacts — they may differ. That is the standard dogbone
layout:

"the y-distance of the contact area need not be the same as the y-distance
(width) of the channel"
— Virginia Tech MICS layout FAQ

"the width of the active area around the contact hole remains constant for
transistors with W_E < W_EDOG"
— Solid-State Electronics 44(1), dogbone geometry in narrow-width MOSFETs

Change

Three coordinated edits, since poly_height, the via arrays and the implants
all derive from the same value:

• __comp_min_width(pdk) — mcon.width + 2*mcon-active_diff.min_enclosure,
  read from the PDK rules rather than hardcoded, so it carries across
  technologies. Falls back to 0.0, preserving current behaviour if the rules
  are unavailable.
• S/D via array and diffusion sized by max(width, comp_min)
• poly_height follows the COMP — otherwise narrow devices trip PL.4_LV
  (poly2 end cap)

~15 effective lines; the rest is comments explaining why.

Verification

Two technologies, no code changes between them — the helper picks up each
PDK's own rules:

PDK	comp_min	W	before	after
gf180	0.36 = 0.22 + 2×0.07	0.22	ValueError	0 violations
		0.28	ValueError	0 violations
		0.36	ValueError	0 violations
		0.50	0 violations	0, geometry unchanged
sky130	0.30 = 0.17 + 2×0.06	0.15	—	0 errors
		0.29 / 0.42 / 1.00	—	0 errors

gf180 via the bundled KLayout deck (FEOL+BEOL); sky130 via Magic DRC.

No regression. At or above the previous minimum the output is identical
polygon by polygon. File hashes do change, because no_exception joins the
via_array signature and gdsfactory derives cell names from parameters — so
the comparison was done on geometry, not on hashes.

Tests

The DRC matrix only exercised composite cells at comfortable widths, so nothing
would catch a regression here. Added nmos/pmos at each PDK's minimum
diffusion width. Both fail on main with CO.4 and pass with this change:

$ python tests/drc/run_cell_drc.py --pdk gf180  --cells nmos_narrow,pmos_narrow
{"pdk": "gf180", "total": 2, "pass": 2, "fail": 0}

$ python tests/drc/run_cell_drc.py --pdk sky130 --cells nmos_narrow,pmos_narrow
{"pdk": "sky130", "total": 2, "pass": 2, "fail": 0}

Note for users

A dogbone device is not electrically equivalent to a rectangular one of the
same W: source/drain resistance is no longer inversely proportional to channel
width, because part of the current flows through the widened diffusion (see the
Solid-State Electronics reference above). Anyone relying on models fitted to
rectangular geometry should re-characterize before using the newly available
widths.

[carloscl03]

The notebook check here is unrelated to this change — main fails the same way.

GLayout_Cells.ipynb hits --cell-timeout 180 on the opamp cell. The reported
NbconvertCrash: nbconvert exit 1 with no output notebook is misleading: the
underlying error is CellTimeoutError, and since nbconvert aborts without
writing the executed notebook, the runner falls into the "crashed before
writing" branch. The real cause only shows up in the artifact log.

It is intermittent rather than broken. Three runs, same container image:

run	GLayout_Cells	result
Aug 5 (#101 branch)	286.5 s	pass
Aug 4 (this PR)	194.9 s	fail
Aug 7 (main)	188.3 s	fail

The failing numbers are time-to-abort, not runtime. In the Aug 5 artifact the
opamp cell took 87 s with per-cell metadata, so a runner roughly 2x slower
crosses 180 s while the other 13 notebooks vary by ±2%.

Reproduced locally with tests/notebooks/run_tutorial_notebooks.py: fails at
the default 180 s, passes at --cell-timeout 600 (610 s total on a slower
machine).

Both DRC jobs pass, including the two narrow-device cells this PR adds.

[carloscl03]

Follow-up: #102 is not a fix for this timeout, but it removes the headroom
problem behind it.

That PR unblocks GLAYOUT_BACKEND=gdstk for the opamp. Same cell, same
parameters as GLayout_Cells.ipynb cell 14, measured on the same machine:

backend	opamp(gf180, ...)
gdsfactory (default)	383.0 s
gdstk	55.5 s

The cell that intermittently crosses --cell-timeout 180 took 87 s on the
runner that passed. At 7x faster it stops being close to the limit at all, on
fast and slow runners alike — so switching the notebook job to the gdstk
backend would be a more durable fix than raising the timeout.

Worth noting gdstk currently fails on the opamp without #102, which is why
this only became measurable now.