msop and son footprints number the right-column pins in reverse (pins 5↔8, 6↔7 swapped on 8-pin parts)

[chayan-1906]

What happens

msop and son place their right-column pins top→bottom, the same direction as the left column. On msop8/son8 that puts pin 5 at the top-right and pin 8 at the bottom-right.

fp.string("msop8").circuitJson()
// pin 5 → (2, +0.975)   top-right ❌
// pin 8 → (2, -0.975)   bottom-right ❌

What should happen

Dual-row packages are numbered counter-clockwise: pin 1 top-left, down the left side, then up the right side, so the last pin sits across from pin 1. That's what every other dual-row footprint in this repo generates:

fp.string("soic8").circuitJson()
// pin 5 → (2.15, -1.905)   bottom-right ✅
// pin 8 → (2.15, +1.905)   top-right ✅

soic, dfn and sop8 use getCcwSoicCoords (the right column starts at -h/2 and goes up), and tssop/ssop do the same in their own coord functions. Only msop and son differ.

Effect

The pad positions look fine in the SVG previews (no pin numbers rendered there), but the pin→pad mapping is mirrored, so a real chip routed with these footprints gets pins 5↔8 and 6↔7 (msop8/son8), 4↔6 (son6), and 6↔10, 7↔9 (msop10) connected to the wrong nets. Affects all variants: msop8/10/12/16, son6/8 (incl. _ep).

Cause

getMsopCoords in src/fn/msop.ts and getSonPadCoord in src/fn/son.ts (identical copies) compute

const rowIndex = (pn - 1) % half
const row = (half - 1) / 2 - rowIndex // same for both columns

so both columns run top→bottom. (vssop.ts has the same helper but compensates by remapping pin numbers before calling it, which is why vssop comes out correct.)

Happy to submit a PR for this.