Reduce network startup and reconnect delays

@rslater-cs y travaille déjà.

Depuis le 9/9/2026.

Network interfaces take too long to become usable and show online after boot or modem reconnection. Remove avoidable delays between modem readiness, interface publication, network activation and UI status updates.

## Evidence

Observed on BigBox SS with firmware `bigbox-ss-v0.11.2-2026-09-09T103923-v22.03.7`, including the HAL late-reply fix from #331:

- GSM discovers and publishes the modem's network interface during its metrics poll. That loop waits before its first iteration; BigBox SS configures a **60-second interval**. See [interface discovery](https://github.com/jangala-dev/devicecode-lua/blob/983a18ee9e984a17e49439a7a14647f30627f5fb/src/services/gsm.lua#L945-L953), [initial polling delay](https://github.com/jangala-dev/devicecode-lua/blob/983a18ee9e984a17e49439a7a14647f30627f5fb/src/services/gsm.lua#L1016-L1034), and [target configuration](https://github.com/jangala-dev/devicecode-lua/blob/983a18ee9e984a17e49439a7a14647f30627f5fb/src/configs/bigbox-ss.json#L613-L625).
- During SSH observation on 9 September 2026, primary was detected at **14:47:39 UTC**, but its `wwan0` binding was not published until **14:48:41 UTC**. ModemManager had already reported the modem connected at **14:47:46 UTC**.
- Separate modem arrivals trigger successive structural network applies. In the initial logs, secondary arrived at **14:38:22 UTC**, primary superseded its apply at **14:38:24 UTC**, and the replacement took **27.1 seconds**.
- Structural applies [reload networking and restart dnsmasq, firewall and mwan3](https://github.com/jangala-dev/devicecode-lua/blob/983a18ee9e984a17e49439a7a14647f30627f5fb/src/services/hal/backends/network/providers/openwrt/init.lua#L45-L52). Logs show existing WAN and cellular connections temporarily disconnecting during these applies.
- [Publishing GSM connection state](https://github.com/jangala-dev/devicecode-lua/blob/983a18ee9e984a17e49439a7a14647f30627f5fb/src/services/gsm.lua#L790-L872) also performs synchronous diagnostic reads, which can delay state delivery when modem requests are slow. Their contribution to the observed delay needs measurement.

The 60-second dependency predates #331. Keep that deadlock fix. Manual SIM swaps may explain the observed modem disappearances; this issue focuses on startup and recovery latency, not diagnosing those disappearances.

## Requested improvements

- Discover and publish the network interface promptly during modem initialization and reconnection, independently of periodic metrics.
- Publish essential connection state without waiting for firmware, band, operator or signal enrichment; update diagnostics separately.
- Coalesce closely spaced interface changes and avoid unnecessary service restarts or repeated activation work.
- Measure elapsed time from modem detection through APN connection, interface publication, network activation and UI readiness using monotonic timestamps. The initial boot logs include a wall-clock correction, so wall-clock timestamps alone are insufficient across that transition.

## Acceptance and validation

- [ ] Healthy interfaces become available without waiting for a metrics interval or optional diagnostic reads.
- [ ] Test cold boot, devicecode restart, SIM reconnection, and both modems arriving close together.
- [ ] Slow diagnostics on one modem do not delay readiness reporting for the other.
- [ ] Verify actual network readiness alongside UI status, and record before/after timings.
- [ ] Add focused GSM/network regressions and run the Lua suite. Preserve existing public interfaces and the #331 deadlock fix.
- [ ] Check the shared behavior for `bigbox-ss`, `bigbox-v1-cm`, and `bigbox-v1-cm-2`; identify which targets receive hardware validation.

Related: #330 tracks the separate case where mwan3 is already online but the UI remains offline. Coordinate the fixes while distinguishing actual connection latency from stale UI status.