pinLabels naming a pin the footprint lacks creates an unroutable port with no error

What happens

pinLabels can name a pin the footprint doesn't have, and core accepts it silently:

<chip name="U1" footprint="soic8" pinLabels={{ pin1: ["A"], pin99: ["Z"] }} />

source_port   9   ← "A", "Z", pin2..pin8
pcb_smtpad    8
pcb_port      8   ← nothing behind "Z"
errors        0

A 9th source port is created for a pad that doesn't exist. Nothing reports it.

Why it matters

Connecting to that pin gives an error that points at the wrong thing:

<trace from=".R1 > .pin1" to=".U1 > .Z" />

pcb_trace_missing_error: Trace [.R1 > .pin1 to .U1 > .Z] is not connected (it has no PCB trace)

The trace is fine — the pin label is wrong. The message sends you to inspect routing instead of the typo, and there's no indication that .U1 > .Z was never routable in the first place.

Cause

Port.doInitialPcbPortRender returns early when a port matches no PCB primitive:

const pcbMatches = matchedComponents.filter((c) => c.isPcbPrimitive)
if (pcbMatches.length === 0) return

The neighbouring case — a port matching multiple non-overlapping pads — already reports source_ambiguous_port_reference. Only the zero-match case is silent.

Important subtlety for whoever fixes this

A blanket check here is wrong. A component with no footprint at all (e.g. a bare <solderjumper />) legitimately has zero PCB primitives, and every one of its pins would be flagged. I hit exactly that: my first version broke 6 existing tests (solderjumper, jumper, panel and subcircuit repros).

The check needs to fire only when the parent component has some PCB primitives but this particular port matches none:

<solderjumper />        → 0 pads total → not a misconfiguration
<chip footprint="soic8" pinLabels={{pin99}}> → 8 pads, pin99 matches none → misconfiguration

PR ready.

Start in Port.doInitialPcbPortRender and compare the zero-match path with the source_ambiguous_port_reference case. Review the existing solderjumper, jumper, panel, and subcircuit tests before changing behavior. Done means an incorrect pinLabels entry on a component with pads reports an error while components with no PCB primitives remain valid.