A board with no DHCP lease is reachable only at 192.168.2.2, the address every board falls back to

When `eth0` gets no DHCP lease, the only address left on a BlueOS device is the static fallback `192.168.2.2/24`, which every other BlueOS device also falls back to. On a bench with more than one vehicle, that fallback is what makes the device unreachable rather than what saves it:

- Two boards in this state on the same switch both answer for `192.168.2.2`, so neither can be reached reliably and there is no way to tell which one replied.
- Reaching one at all needs a dedicated topside interface configured into `192.168.2.0/24`, so with several boards on one router you end up unplugging boards, or running one cable per board, to talk to any of them.
- The hostname does not disambiguate either: every board is `blueos`, and with three of them on the router here `blueos.local` resolved to a different board depending on which resolver answered — `getent hosts` said one address and `avahi-resolve` said another, at the same moment.

Combined with #4233, where the hotspot is destroyed about a minute after boot on the `wpa_supplicant` handler, a board in this state has **no reachable address at all**: no DHCP address, no access point, and a fallback address shared with its neighbours.

That is how it showed up here. A Pi3 looked like a board that would not boot: 20 minutes of power cycling, never appearing on the network. It had in fact booted correctly three times and run BlueOS for about 12 minutes each time, with the version chooser online and every service up. The only way to find that out was to pull the SD card and read the logs on another machine.

## DHCP itself is not broken

Worth stating plainly, because the symptom invites the wrong conclusion. Moving the same Bullseye Pi4 from a segment with no DHCP server onto a router leases immediately:

```
eth0: carrier acquired
eth0: soliciting a DHCP lease
eth0: offered 192.168.0.88 from 192.168.0.1 # 1 s after carrier
eth0: leased 192.168.0.88 for 14400 seconds # 5 s after carrier
eth0: adding default route via 192.168.0.1
```

On that boot `cable-guy` logs a single timeout and **zero** config mismatches, so the retry loop below is specific to having no lease. What this issue is about is the state a board is left in when nothing answers DHCP — which is the normal direct-tether topside setup as much as it is a wrong cable or a dead switch port.

## What the logs show when there is no lease

Pi3, from its SD card, across three boots:

- 107 × `dhclient timed out for interface eth0`
- 0 × `Got new IP ... from DHCP for eth0`
- 106 × `Mismatch detected for eth0: missing dhcp client address`, each re-triggering acquisition about 10 s later

A Bullseye Pi4 on a segment with no DHCP server, up for under an hour: 475 timeouts, 474 mismatch cycles, 0 successes, still looping when it was unplugged.

Two `cable-guy` behaviours make this worse than a plain "nobody answered".

**It cannot tell a lease from a failure.** It runs

```
timeout 5 dhclient -d -v 2>&1 || echo 'timeout'
```

and tests for the word `timeout` before looking for `bound to`. `dhclient -d` stays in the foreground, so `timeout` always kills it and `|| echo 'timeout'` always fires — including when the lease *was* acquired. Running that exact command by hand on a Bookworm Pi4 prints `DHCPACK of 192.168.0.177` and `bound to 192.168.0.177 -- renewal in 5987 seconds`, and still ends in the timeout branch. `Got new IP` appears 0 times in every `cable-guy` log on every board here, including a Bullseye Pi4 that is currently holding a 4 hour lease, so that success branch appears never to be taken in practice: every address these boards have came from `dhcpcd` or NetworkManager instead. #3217 already asks for daemon mode; this is what its absence costs.

**The retry never stops.** Because no client address ever appears, the watchdog treats the interface as mismatched for the life of the boot and re-runs `dhclient` every ~10 s, forever. #3280 is the same loop seen from the static-address side.

Separately, `timeout 5` is shorter than dhclient's own first retry interval — it prints `DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7` — so a single lost DISCOVER cannot be recovered inside the window.

## Environment

- Pi 3B Rev 1.2 and Pi 4B Rev 1.2, Raspberry Pi OS Bullseye, BlueOS `1.4.4-beta.21` (`74fd8595`)
- The lease, when there is one, comes from the host: `dhcpcd` on Bullseye, NetworkManager on Bookworm. The same `cable-guy` code misreports the result on both, it just does not matter while the host succeeds
- `/etc/dhcpcd.conf` also gets a stray `END` line from BlueOS, and `dhcpcd` logs `unknown option: END` on every interface event

## Steps to reproduce

1. Boot a board with `eth0` on a segment where DHCP does not answer — a direct cable to a topside computer with no DHCP server is enough.
2. Watch `cable-guy` log `dhclient timed out` and a config mismatch every ~10 s, with `Got new IP` never appearing.
3. Put a second board in the same state on the same switch, and try to reach either of them at `192.168.2.2`.

## Related

- #4233 — the hotspot dies a minute after boot, removing the other way in
- #3217 — cable-guy should run dhclient in daemon mode
- #3280 — the config mismatch loop
- #3455 — cable-guy failing to get a dynamic address when the router appears late

Start with the cable-guy path that runs `timeout 5 dhclient -d -v ` and the watchdog's `missing dhcp client address` mismatch loop described in the issue. Reproduce on eth0 with no DHCP server and compare it with a router that leases; the issue does not identify a file, test, or specific expected recovery for the shared fallback address and lost access.

Written by the indexing model from the issue text.