fix: draw the sot23 body outline and pin 1 marker (#732)

[DPS0340]

Closes #732.

sot23 (3-pin) was the only SOT in the library with zero silkscreen paths — no body outline, no pin 1 marker. sot23_5, in the same file and same function, already had both.

What this draws

Ported from KiCad's SOT-23-3, whose pads are byte-identical to the ones footprinter already generates, so only the silkscreen needed adding.

The body can't be a closed rectangle: the pads overhang it horizontally (pad 1 spans x[-1.80, -0.475], the body edge is at x = -0.91), so this emits 7 open segments — full-width top and bottom runs, a left edge broken twice by pins 1/2, and a right edge broken by pin 3 — plus the pin 1 chevron. 8 paths total, matching KiCad's 8.

Clearances are derived, not hardcoded: padClearance = strokeWidth / 2 + 0.2, which reproduces KiCad's uniform 0.26 mm and follows the pads if pw/p change, so custom strings like sot23_w3_h1.5_p0.95mm stay correct.

Verification

Geometric, not just visual. Added sot23_3 silkscreen keeps clear of every pad, which densely samples each segment, subtracts the stroke half-width, and asserts ≥ 0.2 mm to every pad:

sot23:    paths=8  minClearance=0.2000mm  ✅
sot323:   paths=2  minClearance=0.3473mm  ✅
sot23w:   paths=2  minClearance=0.3000mm  ✅
sot343:   paths=2  minClearance=0.5050mm  ✅
sot363:   paths=3  minClearance=0.2500mm  ✅

I ran the same check against KiCad's own SOT-23-3 first to confirm the checker agrees with the reference (it reports no overlap there), then used it to catch two bad iterations of my own: my first attempt drew a closed rectangle straight through all three pads, and my second stopped exactly at the pad edges with 0 clearance. Both were rejected before I looked at any SVG.

Both new tests bite. Reverting only src/fn/sot23.ts and re-running:

(fail) sot23_3 draws a silkscreen body outline and pin 1 marker
(fail) sot23_3 silkscreen keeps clear of every pad

The clearance test also asserts silkscreenPaths.length > 0 so it can't pass vacuously if the silkscreen ever disappears again — which is exactly how this bug survived.

Suite: 469 pass / 0 fail, biome format clean, bun run build (ESM + DTS) ok. 4 snapshots updated plus the parity snapshot; I rendered the parity snapshot and compared it side by side against the KiCad reference — the outlines now match, and courtyardDiffPercent stays 0.00%.

Note on the parity test

tests/kicad-parity/sot23_kicad_parity.test.ts reported Diff: 0.00% the whole time the silkscreen was missing, because it compares copper via boolean difference and courtyard area only. The fixture already returns fpSilkscreenElements but no parity test in the repo consumes it. If you'd like, I can open a follow-up that asserts silkscreen presence across the parity suite — I'd expect it to find more cases like this one.