feat: verify/improve cross-platform (multi-board) support beyond rockpi-s

[dubpixel]

Directly relevant to #5 (Companion Dashboard) — upstream's own Linux Server install path targets Raspberry Pi OS / Companion Pi specifically and explicitly doesn't support Raspberry Pi 5. A native Raspberry Pi OS build path here is what would actually let #5 run on real Pi hardware using its supported install method, rather than us adapting it to Armbian. This ticket is effectively a prerequisite for the "display-attached unit" half of #5, not just a loosely related idea.

The actual goal

Handle both sides of the SBC ecosystem, not just one:

• Armbian for the non-Pi board families it supports well (Rockchip, Allwinner, Amlogic, etc.) — this is the existing pipeline.
• Raspberry Pi, via Raspberry Pi OS (the Pi Foundation's own native distro) as a separate build target for real Pi hardware, rather than trying to force Pi support through Armbian.

These are genuinely different pipelines (different base image, different customization tooling than Packer-on-Armbian), so this is a bigger lift than "add a board to the dropdown" — it's closer to a second build path alongside the existing one. Worth it because: Raspberry Pi is the most commonly available/requested platform, and it's what upstream Companion Dashboard (#5) and Companion Satellite's own official installers are built/tested against first -- so a native Pi path would also de-risk both of those integrations.

Current state

• The Packer build pipeline (armbian-builder.yaml) already parameterizes the board — the armbian-board dropdown covers essentially every board Armbian supports, plus a free-text custom-board override. That side is already broad in principle, just narrow in what's actually been tested (see below).
• In practice, only two Armbian-side boards are actually exercised: rockpi-s (real hardware, hand-tested all session) and orangepizero3 (only built in the release-action.yaml matrix, never physically tested as far as this session's work goes).
• No Raspberry Pi / Raspberry Pi OS path exists at all yet.
• Real hardware testing this session surfaced at least one board-specific landmine that would NOT be obvious from the build succeeding: rockpi-s's kernel doesn't reliably create /dev/hidraw* nodes for the Stream Deck after certain USB re-enumeration events, even though CONFIG_HIDRAW=y is set — this is why dpx-deck-splash.py/Satellite use libusb directly instead of hidraw, and why Companion's own hidraw-only surface driver needed a udev-retrigger workaround (see the fnm/hidraw fixes from this session). Whatever the Pi path ends up being, expect similarly board/kernel-specific surprises that only show up on real hardware, not from a successful build.

Ask

• Scope what a Raspberry Pi OS build path would actually require: base image source, customization approach (Packer can likely still drive it, just against a different source image -- or a different tool like pi-gen if that ends up cleaner), and how much of the existing provisioning scripts (install-buttons.sh, install-satellite.sh, install-companion.sh, install-deck-splash.sh) can be reused vs. need Pi-specific variants.
• Once that path exists, wire in Companion Dashboard (feat: optional Companion Dashboard integration #5) via its own supported Raspberry Pi OS / Companion Pi install script -- this is the natural place for the "unit has a display attached" half of feat: optional Companion Dashboard integration #5 to actually land.
• Separately, identify what in this project's own scripts/services makes Armbian/board-specific assumptions today (udev rules, USB/HID enumeration paths, kernel module availability, etc.), since that same audit informs both "which Armbian boards are safe to add" and "what the Pi path needs to handle differently."
• No implementation started -- this is a scoping/tracking issue, prompted by and tied to feat: optional Companion Dashboard integration #5.