Compute Modules skip host setup; BlueOS should run on them with or without a Navigator

## Goal

BlueOS should run on a Compute Module the same way it runs on the corresponding Pi, with or without a Navigator.

CM users are building their own carriers and vehicles. Some put a Navigator on the 40-pin header. Many do not: Holybro Pixhawk + CM4, CSI cameras, custom UART autopilots. Official support is still “Pi 4B / Pi 5 + Navigator”, but the install script is already the path we tell those users to take, and it should leave them with a working BlueOS host either way.

Navigator detection is a later, optional step. It must not be the only reason we recognise the board.

## How those users actually install

Blue Robotics does not build images on CM hardware, and the shipped `.img` often will not boot a CM4 eMMC (`This board requires newer software`). The documented workaround is: flash Raspberry Pi OS for that module, then run `install.sh` / `configure_board.sh` **on the module**. That is when board detection sees `Raspberry Pi Compute Module 4/5 …`, not a Pi4/Pi5 builder.

See:

- https://github.com/bluerobotics/BlueOS/issues/3169
- https://discuss.bluerobotics.com/t/blueos-not-booting-on-cm4-with-emmc/17674
- https://discuss.bluerobotics.com/t/using-navigator-with-rpi-cm4-waveshare-carrier-board/23155
- https://discuss.bluerobotics.com/t/various-issues-running-blueos-on-pi-cm4/17595
- https://discuss.bluerobotics.com/t/if-the-navigator-supports-the-rpi-4-does-it-mean-it-supports-the-rpi-cm4-too/22245

## Problem

The two mechanisms that are supposed to configure the host disagree about which board they are running on, and one of them still treats an unmatched CM as success.

### Install: a CM5 (and a CM3) never gets a board script

`install/boards/configure_board.sh` dispatches on `/proc/device-tree/model`:

```sh
if [[ $CPU_MODEL =~ Raspberry\ Pi\ [0-3] ]]; then # bcm_28xx.sh
elif [[ $CPU_MODEL =~ (Raspberry\ Pi\ [4])|(Raspberry\ Pi\ Compute\ Module\ 4.*) ]]; then # bcm_27xx.sh
elif [[ $CPU_MODEL =~ Raspberry\ Pi\ 5 ]]; then # bcm_2712.sh
else
board_not_detected "/proc/device-tree/model" "$CPU_MODEL"
```

A CM4 is matched explicitly, so `install.sh` on a CM4 does run `bcm_27xx.sh` (cgroups, serial console, dwc2, and — if present — Navigator overlays).

A CM5 reports `Raspberry Pi Compute Module 5 Rev ...`, which matches none of the three branches, so it falls through to `board_not_detected` and **no board script ever runs**. Docker cgroups, the serial console that occupies the UART, USB gadget (`dwc2`), and any Navigator overlays stay as the stock Raspberry Pi OS image had them. The same is true of a CM3, which does not match `Raspberry Pi [0-3]` either.

The install does not fail: `board_not_detected` prints a report-this-line message and returns 0. The user gets a BlueOS that boots and then looks “half installed”.

That is independent of Navigator. A CM5 used only as a companion computer still needs the host configuration the Pi5 script would have applied.

### Runtime: a CM4/CM5 is `CpuType.Other` on 1.4

`get_cpu_type()` in `core/libs/commonwealth/commonwealth/utils/general.py` matches on model strings a Compute Module does not have (on `1.4-dev`):

```python
if "Raspberry Pi 4" in line: # does not match "Raspberry Pi Compute Module 4"
return CpuType.PI4
```

So every board-dependent patch in `blueos_startup_update.py` bails out — including ones that are not Navigator-specific (`update_dwc2`, `update_cgroups`, `clean_config_pi3`). Navigator overlay updates fail for the same reason, which is why a CM4 with a Navigator on the header still only offers SITL.

This half is already fixed on `master` by https://github.com/bluerobotics/BlueOS/pull/4011 (verified on physical CM4 and CM5, with a Navigator). The 1.4 backport is https://github.com/bluerobotics/BlueOS/pull/4077. It does not change `configure_board.sh`.

## Impact

- A CM5 user following the install-script workaround gets no Pi5 host configuration, with or without a Navigator, and no error.
- A CM4 user following the same path does get the install-time script, but on 1.4 nothing later maintains `config.txt` or treats the board as a Pi4 (Navigator detection included).
- CM3 is in the same install-time hole; Navigator is not relevant there (pinout). BlueOS as a companion OS still should be.

## Environment

- `configure_board.sh` is the same on `1.4-dev` and `master` (CM4 yes, CM5/CM3 no).
- `get_cpu_type()` recognises CM4/CM5 on `master` only, until #4077 lands.
- Model strings confirmed in #4011: `Raspberry Pi Compute Module 4 Rev 1.1`, `Raspberry Pi Compute Module 5 Rev 1.0`.

Start with install/boards/configure_board.sh and the bcm_27xx.sh and bcm_2712.sh scripts, then compare their board handling with get_cpu_type() in core/libs/commonwealth/commonwealth/utils/general.py. Check the referenced startup behavior and existing CM4/CM5 fixes before changing the install path. Done means CM3, CM4, and CM5 receive the appropriate host setup with or without a Navigator, and unmatched boards no longer report success.

Written by the indexing model from the issue text.