fuseProps accepts any string as a connections key, unlike every other component

[DPS0340]

Summary

fuseProps accepts any string as a connections key. A typo'd pin name — or a key that isn't a pin at all — passes validation silently, where every other component rejects it.

const typo = { pin99: ".R1 > .pin1" }

fuseProps.safeParse({ name: "F1", currentRating: "1A", connections: typo })
// → success: true   ❌

capacitorProps.safeParse({ name: "C1", capacitance: "1uF", connections: typo })
// → success: false  ✅
resistorProps.safeParse({ name: "R1", resistance: "1k", connections: typo })
// → success: false  ✅

A fuse is a two-pin passive exactly like a resistor or capacitor, so there's no reason for it to behave differently here.

Everything gets through:

connections	result
{ pin1: "..." }	accepted (correct)
{ pin99: "..." }	accepted
{ "not a pin at all": "..." }	accepted
{ "": "..." }	accepted

The empty-key case is worth calling out: "" isn't a selector, and downstream that produces an internal CSS-parser error rather than anything actionable (I filed that side of it as tscircuit/core#2865).

Cause

Two related gaps in lib/components/fuse.ts.

1. It hand-rolls the connections schema instead of using the shared helper. Every other component builds it from its own pin labels:

// capacitor.ts, resistor.ts, ...
connections: createConnectionsProp(capacitorPinLabels).optional(),

createConnectionsProp keys the record on z.enum(labels), so unknown keys fail. Fuse instead does:

// fuse.ts
connections: z
  .record(z.string(), z.union([...]))    // ← any key passes
  .optional(),

The file already defines fusePinLabels = ["pin1", "pin2"] and exports it — it just isn't used for this.

2. Nothing checks the schema against the interface. FuseProps declares connections?: Connections<PinLabel> while the schema produces Record<string, ...>. That mismatch is exactly what expectTypesMatch exists to catch, and fuse is the only component in lib/components/ that exports both an interface and an Inferred* type without calling it. (I checked all 20 files that omit expectTypesMatch; the rest don't export both, so fuse is the single gap.)

Adding the check to the current file proves the drift:

error TS2345: Argument of type 'true' is not assignable to parameter of
type '"property connections has mismatched types"'.

So the invariant the repo relies on was never applied here, and the types silently diverged.

Expected

fuseProps should build connections from fusePinLabels like every other component, and the file should carry the expectTypesMatch assertion so this can't drift again.

PR follows.