ci: run the tutorial notebooks on gdstk

[carloscl03]

The Run tutorial notebooks check currently passes or fails on identical content, depending on which runner the job lands on. Two notebooks sit right on the 180s per-cell limit:

GLayout_Cells   290s pass (#112 run) / 372s error (#113 run)
glayout_opamp   136s pass (#112 run) / 198s error (#113 run)

lvs-pin-filter alone has four green runs and two red ones. Right now six of the eight open PRs are red for this reason while their DRC checks pass.

Raising the timeout would hide it. The native backend removes it: the same cells build several times faster, so they end up nowhere near the limit.

Measured

Run on this fork's CI — same container, same image, same runners — with #102, #104 and #113 applied on both sides. The only difference between the two branches is the one line in this PR:

notebook	gdsfactory	gdstk
GLayout_Cells	187.8s ERROR (timeout)	14.2s pass
glayout_opamp	126.4s pass	19.2s pass
glayout_tutorial_5T_OTA_part2	90.8s pass	16.2s pass
test_bjt_custom_pattern	68.2s pass	11.4s pass
test_bjt_glayout	33.8s pass	7.5s pass
whole suite	660s — 13/14	158s — 14/14

Runs: gdsfactory baseline · gdstk

Worth noting that the baseline already carries all three PRs and still fails. They are what lets the notebooks run on gdstk at all — they are not themselves a fix for the timeouts.

Dependencies

This check stays red until all three land, and each covers a different failure in the same notebook:

• without mimcap: build with extensions again #113 — GLayout_Cells raises in mimcap.py:293
• without Fix order-dependent port renaming; close gdstk backend gaps #102 — it raises in Component.add
• without gdstk backend: close API gaps so the tutorials run #104's add_ref(columns=) — test_bjt_gdsfactory raises

Happy to hold this until they are in, or to close it if you would rather solve the flakiness another way — the measurement is the part worth having either way.