Rebuild the connector catalog with gendered Male/Female port types

Replaces the old ungendered catalog (plain XLR, TS/TRS 1/4", Speakon
NL2/4/8, etc.) with a full Male/Female-aware set covering audio, video,
network/data, USB (with Host/Device role split for USB-C), power, RF coax,
and fiber connectors, plus real-world bridging/adapter cables — enough to
model gender benders and specify exact cable types in the BOM instead of
just a connector family. The catalog now lives entirely in the DB (seeded
via supabase/seed.sql, captured with the new export-seed.mjs) rather than
partly hardcoded in domain/library.ts, which is now unused.

Existing seeded diagrams/devices were intentionally not migrated to the
new port types — there was nothing important in them yet.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017DUU6CnxECCDeqDNYJgr5x

organized-ideas.md

@@ -67,6 +67,7 @@ Stated explicitly during planning: this needs to run **entirely locally** during
   - **Impact check before an Admin acts.** Before an edit-submission is approved (or a Super Admin edits/hides a public entry directly), they see how many diagrams reference that entry and a short sample (diagram name + owner username) — computed by a privileged, admin-only function that returns only that aggregate, *not* raw access into other users' diagram contents. Regular Admins still don't get diagram visibility (only Super Admins do, per §6) — this doesn't change that boundary, it just answers "what's the blast radius" without needing it.
   - **Public catalog entries are never hard-deleted**, only hidden/unpublished from new use (the same pattern already used for hiding built-in device templates) — closes off the one scenario (an entry disappearing out from under a diagram, showing "Unknown type") that live references can't otherwise defend against.
 - **Decided: site-wide announcements.** A new lightweight concept: an Admin can post a dismissible banner that every signed-in user sees (e.g. "the XLR-to-TRS adapter cable's compatibility changed on 2026-09-08, check any diagrams using it") — offered as a follow-up step right after acting on an impact-flagged change, so users aren't surprised by something that already shipped.
+- **Future TODO, not yet built: a real `role` concept on `PortType`.** Surfaced while building the gendered connector catalog (2026-09-27) — `family`/`compatibleFamilyIds` alone can express "these two types may connect" but not "these two ports are the *same* declared type and must *not* self-pair" (e.g. USB-C Host must not wire to another USB-C Host). The compatibility engine's base rule is "identical family is always compatible," which every ordinary gendered pair relies on (two "XLR (Female)" ports on different devices should connect via a cable) but which makes true role exclusivity (Host-vs-Host, Device-vs-Device) currently unenforceable through catalog data alone. Fixing it needs an actual code change in `compatibility.ts` (an explicit role field + logic, not just another family flavor). Low-stakes today — USB-C Host/Device is the only pair using it — deliberately deferred rather than built speculatively.
 
 ## 4. Canvas — Compact & Expanded Device Views