cable-guy BackupServer DHCP on eth0 steals lab leases from other vehicles

## Problem

On a switch that already has a LAN DHCP server, one BlueOS vehicle's **Backup DHCP Server** (`dnsmasq` on `eth0`, gateway `192.168.2.2`, range `192.168.2.101–200`, `--dhcp-rapid-commit`) can win `dhcpcd` on **another** vehicle. After reboot that second vehicle loses its unique LAN address and default route, and is only on `192.168.2.0/24` (plus the shared static `192.168.2.2`).

BackupServer is supposed to start only when no other DHCP server is found ([#3143](https://github.com/bluerobotics/BlueOS/issues/3143), implemented in [#3154](https://github.com/bluerobotics/BlueOS/pull/3154)). That check did not prevent `dnsmasq` on `eth0` here.

## What we saw

Client (lost its LAN IP):

- Raspberry Pi 4 Model B Rev 1.2, Raspbian 11 bullseye
- BlueOS `bluerobotics/blueos-core:1.4.4-beta.23`
- Host `dhcpcd` on `eth0`

Servers (BackupServer actually running on `eth0`):

- Pi 5 at `192.168.0.124`, BlueOS `1.4-dev` (bookworm)
- Pi 5 at `192.168.0.147`, BlueOS `1.4-dev` (bookworm)
- Both had:
`dnsmasq --interface=eth0 --dhcp-range=192.168.2.101,192.168.2.200 --dhcp-rapid-commit`

Lab DHCP `192.168.0.1` was up the whole time. On a previous boot the Pi4 had:

```
eth0: offered 192.168.0.88 from 192.168.0.1
eth0: leased 192.168.0.88 for 14400 seconds
eth0: adding default route via 192.168.0.1
```

After a reboot, the same `dhcpcd` did:

```
eth0: soliciting a DHCP lease
eth0: probing address 192.168.2.176/24
eth0: leased 192.168.2.176 for 86400 seconds
eth0: adding route to 192.168.2.0/24
```

The lease file named server `192.168.2.2`. There was **no** default route via `192.168.0.1`. The Pi was unreachable at `192.168.0.88` (LEDs up, no ARP on `192.168.0.0/24`). It still answered ARP for `192.168.2.176` on the same cable.

The Pi4 itself did **not** start `dnsmasq` on `eth0`. It was only a DHCP **client** of the other boards' BackupServers.

`dhcpcd --request 192.168.0.88` still got `192.168.2.176` until `dnsmasq --interface=eth0` was stopped on the two Pi5s. Then the lab router offered `192.168.0.88` again.

## Steps to reproduce

1. Put at least two BlueOS boards on the same L2 as a normal LAN DHCP server (here `192.168.0.1`).
2. Leave default cable-guy `eth0` config (`192.168.2.2` BackupServer + DHCP client).
3. Confirm at least one board is running `dnsmasq --interface=eth0` with the `192.168.2.101–200` range (BackupServer started anyway).
4. Reboot another board that previously held a LAN lease (e.g. `192.168.0.88` from `192.168.0.1`).
5. After boot, `dhcpcd -U eth0` shows `ip_address=192.168.2.176` and `dhcp_server_identifier=192.168.2.2`, and there is no default route via the lab gateway.

## Related

- [#3143](https://github.com/bluerobotics/BlueOS/issues/3143) (closed) / [#3154](https://github.com/bluerobotics/BlueOS/pull/3154) — BackupServer should not run when another DHCP server is already on the network
- [#4236](https://github.com/bluerobotics/BlueOS/issues/4236) — when there is no unique LAN lease, the only remaining address is the shared `192.168.2.2`
- [#3223](https://github.com/bluerobotics/BlueOS/issues/3223) (closed) — BackupServer offers no router; a stolen lease therefore also drops the default route
- [#4054](https://github.com/bluerobotics/BlueOS/issues/4054) — `dhcpcd` and cable-guy's static `192.168.2.2/24` on the same interface fighting over `192.168.2.0/24`

Start with the BackupServer behavior implemented for #3154, focusing on dnsmasq on eth0 and how it checks for an existing DHCP server. Reproduce the competing offers with dhcpcd and inspect the related issues #3143 and #4236. Done means BackupServer does not offer leases on a shared LAN with an active DHCP server, so another board retains its LAN address and default route.

Written by the indexing model from the issue text.