chore(usb): migrate all VID/PID catalogue data to FastLED/boards

[zackees]

Context

fbuild still carries USB VID/PID knowledge in repository-owned code, fixtures, and the legacy online-data-tools pipeline. The canonical source is now the published FastLED/boards registry, and fbuild must ingest that registry rather than maintain a second catalogue.

A current repository sweep found, among other examples:

• online-data-tools/fetch_raspberrypi_usb_pids.py and other vendor fetchers with vendor/PID allocation logic
• online-data-tools/seed_mcu_to_vid.json with board-family VID heuristics
• crates/fbuild-core/src/usb/embedded.rs and the checked-in vendor archive
• test fixtures and docs that encode concrete VID/PID rows
• serial/deploy classification tables and board metadata that may duplicate registry identities

Some literals are legitimate protocol constants or test fixtures; the audit must classify rather than blindly delete them.

Proposal

Scour the entire fbuild repository for USB VID/PID data and classify every occurrence as one of:

1. canonical board/device data that belongs in FastLED/boards;
2. a protocol/specification constant that is not a device catalogue entry;
3. a test-only fixture, which may remain only when clearly isolated and labelled; or
4. an unsafe runtime duplicate that must be removed.

For category 1, add provenance-backed records to the correct FastLED/boards data branch and regenerate/publish through the boards pipeline. Update fbuild's build/cache ingestion to consume the published boards artifacts. Remove runtime fallbacks and generated/bundled catalogues that duplicate those records. Keep only narrowly-scoped protocol constants and synthetic/test fixtures, with comments explaining why they are not production data.

The audit must include Rust, Python, JSON, docs, generated assets, release packaging, and tests; search case-insensitively for both symbolic names and numeric forms (VID, PID, VID:PID, 0xNNNN, and hex strings).

Acceptance criteria

• A checked-in audit lists every concrete USB VID/PID occurrence and its classification.
• All board/device VID/PID records have a corresponding FastLED/boards source/provenance entry; missing records are added there, not fbuild.
• Production fbuild contains no embedded or hard-coded board/device VID/PID catalogue and does not silently fall back to one.
• Build/cache ingestion consumes the published FastLED/boards artifact and validates its schema/version.
• Test-only fixtures are explicitly marked and cannot become runtime defaults.
• Existing serial/deploy behavior remains covered by tests, including RP2040 BOOTSEL 2e8a:0003, runtime CDC IDs, NXP/LPC identities, and unrelated CP210x negative cases.
• Remove or deprecate the legacy fbuild online-data USB catalogue path once boards ingestion is proven, with migration notes.
• CI grep/lint guard prevents new production VID/PID catalogue literals outside approved protocol/test locations.
• Link the migration PR(s), boards data PR(s), and regenerated publication artifact in this issue.

Related work

• research: audit and publish Pico/Pico 2 USB identities boards#46 — Pico/Pico 2 USB identity research and publication.
• feat(rp2040): zero-touch deployment to an as-received Pico via ROM UF2 #1040 — stock RP2040 deployment parent.
• usb: ingest VID/PID data from FastLED boards #1045 and fix(rp2040): encode complete firmware at XIP address #1046 — initial boards ingestion and UF2 address correction.

[zackees]

Strict audit found the current published boards artifact cannot replace fbuild transport semantics. FastLED/boards#47 now specifies the typed identity/profile contract for runtime CDC, bootloader, bridge, probe, recovery, reset transitions, board aliases, collisions, provenance, and schema validation. It is attached as a child dependency. PR #1052 must remain open until its audit includes board assets, MCU heuristics, embedded vendor archives, and root legacy catalogues; the production tables cannot remain at #1047 closeout.

[zackees]

Preparatory milestone merged: #1052 at 1f843fa. It records the production catalogue surfaces and prevents growth in its explicitly scoped pair/board-JSON patterns; it does not claim the final deny-all invariant. The typed registry dependency is attached as child FastLED/boards#47, with schema implementation in FastLED/boards#48. Final #1047 closeout still requires published semantic data, fbuild ingestion, removal of embedded board/vendor/MCU/runtime/probe tables and legacy pipelines, and a repository-wide zero-production-literal guard.