Show the component libraries in the palette

[ledogar]

Second of the PRs offered in #272. Independent of #1 — either can merge first — though #1 makes this one easier to verify, since the suite currently can't be run as a whole.

Not a macOS change, like the last one. Found while adopting your branch; the behaviour is (according to Claude, running on my MacOS) "identical on Linux".

The gap

The palette lists component types — a generic BJT, Diode, JFET — from a hardcoded array plus a reflection scan. The part libraries in Circuit/Components/*.xml are never read, so the ~87 parts in them can't be reached from the editor. Placing a 2N3904 means dropping a bare BJT and typing IS, BF, BR by hand; the tube models are effectively unusable.

GUI_PORT_PLAN.md:85 lists "component library insertion" under Phase 3, so this looked known-incomplete rather than deliberate — but do say if it was intentional and I'll drop this.

What it does

ComponentLibrary reads the same XML the WPF app does: a Library element of Component elements, each handed to Circuit.Component.Deserialize.

The palette becomes a tree of collapsible categories, because a flat list would put the generic Diode at the same level as the sixteen specific ones with only a trailing "s" between them — and 110 entries is a lot to scan. The tiers follow the WPF app (ComponentLibrary.xaml.cs builds Common, then Generic, then the libraries), names included, so it's familiar coming from Windows:

Common (10)      everyday parts, expanded by default
Generic (22)     the reflection-discovered component classes
Diodes (16)  Op-Amps (12)  Transistors (47)  Tubes (12)

Both Diode entries earn their place — the generic one is what you need for a part the libraries don't carry, or to hand-tune a model. Headers carry counts, and a filter box narrows the list; filtering expands every category that matched, since results hidden behind a collapsed header would defeat the search.

Two details worth a look

Fresh instance per placement. Each LibraryPart keeps its source XElement rather than a deserialized prototype and deserializes again for every placement. Components are mutable, so a shared prototype would let an edit to one placed part show up in the next one. There's a test for it, and I also checked it by hand — place two 2N3904s, set BF=999 on one, the other still reads 300.

The libraries weren't reaching the build output. Circuit.csproj marked all four XML files as Content but set CopyToOutputDirectory on Tubes.xml alone — so even with this code, a host looking beside its executable would find one library out of four. Fixed with a wildcard. That's the only change outside LiveSPICE.Avalonia.

Verified on this branch

Builds clean; all four libraries reach the output; ComponentLibraryTests 3/3, SchematicCanvasInteractionTests 10/10, AppSettingsTests 3/3 (run per-class, since the suite still hangs without #1); palette renders as described.

🤖 Generated with Claude Code