pinheader emits string pins in schematic port_arrangement, failing circuit-json's parser

A <pinheader> makes the board's circuit-json fail circuit-json's own parser (any_circuit_element).

What happens

Building a board with a <pinheader> produces a schematic_component that fails circuit-json's own parser. Both any_circuit_element.safeParse(...) and schematic_component.safeParse(...) return success: false for that element, so the board's circuit-json no longer validates against the schema it is meant to match. Pin headers are a common part, so this affects a lot of boards.

Repro

import { any_circuit_element } from "circuit-json"

circuit.add(
  <board width="20mm" height="20mm">
    <pinheader name="J1" pinCount={2} footprint="pinrow2" />
  </board>,
)
await circuit.renderUntilSettled()

const sc = circuit
  .getCircuitJson()
  .find((e) => e.type === "schematic_component")

// sc.port_arrangement.right_side.pins === ["pin1", "pin2"]
any_circuit_element.safeParse(sc).success // false

Cause

The emitted schematic_component.port_arrangement.<side>.pins is an array of label strings ["pin1", "pin2", ...], but circuit-json's schematic_component_port_arrangement_by_sides schema requires pin numbers:

left_side: z.object({ pins: z.array(z.number()), /* ... */ }).optional()

so the string pins fail validation. Chips emit port_arrangement: undefined and parse fine, so this is specific to the pin header building string pins.

Environment

• @tscircuit/core at HEAD fe733758
• circuit-json 0.0.464

Start with the pinheader schematic_component generation reached by circuit.add and circuit.getCircuitJson(), then run the provided reproduction with any_circuit_element.safeParse and schematic_component.safeParse. Trace the port_arrangement output and add or update coverage so a two-pin header produces circuit-json that both schemas accept.