fix: require pinHeader pinCount to be a positive integer (#756)

[adityaaa-IIT-BHU]

Fixes #756

Problem

pinHeaderProps.pinCount was a bare z.number(), so fractional, zero, negative and infinite values all parsed successfully.

The fractional case is the damaging one — it produces a header whose port count and pad count disagree, with no error:

pinCount	source_ports	pads	errors
2	2	2	0
2.5	2	3	0
3	3	3	0
3.7	3	4	0

Every whole number agrees; every fractional one leaves a pad with no port behind it, and it renders and exports without complaint.

Zero and negative counts failed too, but later and less clearly:

pinCount=-4  →  0 ports, 0 pads, 1 error: pcb_missing_footprint_error
pinCount=0   →  0 ports, 0 pads, 1 error: pcb_missing_footprint_error

pcb_missing_footprint_error points at the footprint. The mistake was the pin count.

At the schema level, before this change:

pinHeaderProps.safeParse({ name: "H1", pinCount: 2.5 })       // success ✅
pinHeaderProps.safeParse({ name: "H1", pinCount: -4 })        // success ✅
pinHeaderProps.safeParse({ name: "H1", pinCount: 0 })         // success ✅
pinHeaderProps.safeParse({ name: "H1", pinCount: Infinity })  // success ✅

(NaN was already rejected — zod's z.number() excludes it but not Infinity.)

Change

A count of physical pins is inherently a positive integer, but nothing said so. This uses the idiom already present in the repo — analogacsweepsimulation.ts uses z.number().int().positive() for sampleCount and samplesPerInterval — with messages that name the prop:

pinCount: z
  .number()
  .int("pinCount must be a whole number of pins")
  .positive("pinCount must be greater than zero"),

2.5       →  pinCount must be a whole number of pins
0         →  pinCount must be greater than zero
-4        →  pinCount must be greater than zero
Infinity  →  pinCount must be a whole number of pins

.int() covers Infinity as well, since Number.isInteger(Infinity) is false.

Compatibility

Valid counts keep parsing to the same value, so no real header changes behaviour. The four newly-rejected inputs were all already broken downstream — either as a mismatched pad/port count or as a misleading pcb_missing_footprint_error — so this converts silent or misattributed failures into a parse-time error naming the prop.

Generated docs were refreshed per AGENTS.md; the only diff is the pinCount block in COMPONENT_TYPES.md.

Verification

• bun test — 416 pass / 0 fail (was 412; +4 new tests in tests/pin-header.test.ts)
• bunx tsc --noEmit — clean
• bun run format:check — clean
• git diff --check — clean