fix: validate fuse connections against its pin labels (#754)

[DPS0340]

Fixes #754.

What was wrong

fuseProps accepted any string as a connections key. Same typo, same class of component, opposite result:

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

fuseProps.safeParse({ name: "F1", currentRating: "1A", connections: typo })      // success ❌
capacitorProps.safeParse({ name: "C1", capacitance: "1uF", connections: typo })  // fails   ✅

{ "not a pin at all": ... } and { "": ... } got through too.

Two gaps caused it:

1. The schema was hand-rolled. Every other component does createConnectionsProp(<its>PinLabels), which keys the record on z.enum(labels). Fuse used a bare z.record(z.string(), ...), so any key passed — even though the file already defines and exports fusePinLabels = ["pin1", "pin2"].

2. Nothing held the schema to the interface. FuseProps declared connections?: Connections<PinLabel> while the schema produced Record<string, ...>. Fuse is the only file in lib/components/ that exports both an interface and an Inferred* type without calling expectTypesMatch — I checked all 20 files that omit it, and the other 19 don't export both, so this was the single gap. Dropping the assertion into the file as-shipped fails to compile:

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

The types had silently drifted because the invariant was never applied here.

The fix

Three lines of substance, all bringing fuse in line with the existing convention:

• connections: createConnectionsProp(fusePinLabels).optional() — the same helper and the same pin-label source everything else uses.
• connections?: Connections<FusePinLabels> on the interface, matching how CapacitorProps and ResistorProps pin theirs to concrete labels rather than the free PinLabel parameter.
• expectTypesMatch<FuseProps, InferredFuseProps>(true) at the bottom, so this can't drift again.

No new helper, no new convention — the repo already had all of it.

Tests

tests/fuse-connections.test.ts, five tests pinning both directions:

case	expected
pin1, pin2, and both together	accepted
pin99, "not a pin at all", ""	rejected
the same typo through fuseProps vs capacitorProps	results must be equal — asserted by comparison, not against a hardcoded false
array and readonly array targets on pin1	still accepted
no connections at all	still accepted (stays optional)

The comparison test is the one that matters: it fails if fuse and the other two-pin passives ever disagree again, in either direction. The last two rows are guard rails against over-tightening — a change that simply rejected more would break them.

Bite-proofed: reverting only lib/components/fuse.ts takes the file from 5 pass to 3 pass / 2 fail.

Verification

bun test: 388 pass / 0 fail (baseline on main is 383 pass / 0 fail; +5 new). bunx tsc --noEmit clean — which is itself part of the fix, since the new expectTypesMatch would fail the type-check if the schema and interface disagreed. bun run format:check clean.

[DPS0340]

Withdrawing this one on queue grounds rather than anything about the change itself.

I counted my own output across every repo I contribute to. Among PRs a maintainer actually decided, 57% merged — but 94% of what I have opened has never been looked at by a human at all. The constraint was never quality; I was handing out more review work than anyone could absorb.

This PR fixes an issue I filed myself, which is the shape most of that volume took: find something, report it, fix it, and hand a maintainer work nobody asked for. I am closing the self-originated ones across every repo and keeping only those that answer someone else's bug report.

The branch stays up and the issue stays open, so nothing is lost. If this one is actually wanted, say so and I will reopen it.

Sorry for the noise.