feat: support explicit pinrow courtyard dimensions

[rushabhcodes]

Why

The SparkFun RFM69 breakout work in tscircuit/sparkfun-boards#325 exposed a valid layout that the generated pinrow courtyard cannot currently represent. The board uses separate 5-pin and 3-pin header components placed end-to-end as a contiguous breakaway header. Their physical bodies touch, but each generated courtyard includes the standard clearance, so the two courtyards overlap.

The existing default should not be reduced globally: comparisons with equivalent KiCad 2.54 mm vertical pin-header footprints show that footprinter's calculated courtyard is already slightly smaller and intentionally preserves normal component-clearance behavior. A relative margin modifier would also be ambiguous because its reference geometry would need to be defined.

Exact courtyard width and height are unambiguous and already follow the cyw/cyh convention used by smdpads and custom passive footprints. Extending that convention to pinrow allows exceptional mechanical layouts to specify their actual courtyard without changing every existing pinrow footprint.

Example:

pinrow3_p2.54_id1.016_od1.88_cyw8.12mm_cyh3.04mm

What changed

• add optional cyw and cyh parameters to pinrow and headermodule
• use the supplied values directly as the courtyard rectangle dimensions
• require cyw and cyh to be provided together so a partial override cannot be silently misinterpreted
• preserve the existing calculated courtyard when neither parameter is supplied
• expose both parameters through the typed builder API
• add direct dimension assertions and a visual SVG snapshot

Compatibility

This is opt-in. Existing footprint strings generate the same courtyard as before.

Testing

• bun test: 567 tests passed
• bun run build
• bunx biome check src/fn/pinrow.ts src/footprinter.ts tests/pinrow.test.ts

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.