fix: draw silkscreen outlines for sod123 and sot723 (#734)

[DPS0340]

Completes #734 — the last two findings from the scan. Independent of #735 and #736 (different files, no conflicts).

Both were the only members of their families shipping bare pads:

sod123    silkPaths=0   ← this PR
sod123f   1     sod123w  1     sod123fl 1
sod323    1     sod523   1     sod923   1     sod128  1

sot723    silkPaths=0   ← this PR
sot23w 2   sot323 2   sot343 2   sot363 3   sot563 3   sot25 3

(sot23 was the third, fixed in #733.)

Why I didn't just copy the sibling formula

sod123f builds its outline at y = ±h/2. Applying that here would have made things worse, not better — I checked before writing it:

sod123 defaults: h=1.22 → ±0.610
pads span y[-0.600, 0.600]
gap = 0.010, minus the 0.05 stroke half-width → -0.040   ← silk on copper

h is the body height (1.22 mm) while the pads are 1.2 mm tall, so the pads are effectively as tall as the body. Both outlines are therefore derived from the pads:

const silkPadClearance = 0.2 + strokeWidth / 2
const outlineHalfHeight = padHalfWidth + silkPadClearance

sod123 keeps the right side open so it never crosses pad 2, and puts the vertical edge outboard of pad 1 to mark the cathode end — the shape KiCad's D_SOD-123 uses. sot723 gets the two horizontal runs above/below the pads, matching KiCad's SOT-723.

For sot723 I also took the pad extents from getCcwSot723Coords instead of hardcoding the ±0.4 offsets, and left the clamp in place for any pad that reaches into a run's y-band, so the outline follows if that geometry is ever parameterised.

Verification

              before        after
sod123    no silkscreen    0.2000
sot723    no silkscreen    0.2000
sod123f       0.4000       0.4000   ← unchanged
sod123w       0.2000       0.2000   ← unchanged
sod123fl      0.3220       0.3220   ← unchanged
sod128        0.3500       0.3500   ← unchanged
sod323        0.2500       0.2500   ← unchanged

A bug the checker caught in my own work: my first sot723 attempt produced runs only 0.1 mm wide instead of spanning the body. The clamp was firing on the outermost pad because runY lands exactly on the clearance boundary and the comparison was strict. Changed to >=/<= so grazing the boundary isn't treated as a collision — runs are now the full ±0.6 body half-width, close to KiCad's ±0.3…0.7.

Bite proof, checked separately per file. Reverting only sod123.ts → "hasSilkscreen": false for sod123; reverting only sot723.ts → same for sot723. The test asserts presence and clearance, so it can't pass vacuously.

Suite: 468 pass / 0 fail, biome format clean, bun run build ok. Courtyard parity unchanged — D_SOD-123 and SOT-723 both still report IoU 100.00% (diff 0.00%). I rendered the sod123 parity snapshot against the KiCad reference and the outlines line up.

Scan status

With this, all 4 "no silkscreen where KiCad has some" findings from #734 are addressed except pinrow6_rows6_od1.7_id1, which is a through-hole part where KiCad's reference is a different connector family — I'd rather not guess at that one. The ~25 footprints sitting between 0.045 and 0.15 mm (tight vs IPC 0.2 but not overlapping) are still listed in #734 if you want them tightened as a follow-up.