## What happened

Opening the internet speed test (network panel -> speed test, `omarchy.speedtest`)
regularly shows **0 on both the download and upload dials**. No error is
displayed — the dials simply never move off zero.

## Expected

Each dial shows the measured throughput, as `omarchy-network-speedtest` reports
it on stdout.

## Root cause

`shell/plugins/panels/speedtest/Panel.qml` gives each direction a fixed 5-second
window that starts **when the process is launched**:

```qml
function startPhase(nextPhase) {
  ...
  speedTestProc.running = true
  phaseTimer.restart()        // 5000 ms, measured from launch
}
```

But `bin/omarchy-network-speedtest` cannot emit its first sample until it has:

1. fetched the Netflix OCA endpoint list from `api.fast.com`,
2. spawned its 8 traffic workers, and
3. completed one `sleep 1` sampling interval.

That warm-up is most of the budget, so `phaseTimer` fires and SIGTERMs the
script after only a fraction of a second of real measurement — and when the
`api.fast.com` call is slow, before the script has printed anything at all.
With no line parsed, `downloadMbps`/`uploadMbps` stay `""` and `toMbps()`
returns 0.

## Steps to reproduce

Time how long the helper takes to produce its first line:

```bash
time omarchy-network-speedtest down | head -1
time omarchy-network-speedtest up   | head -1
```

Then open the speed test panel and compare against the 5s phase timer.

## Measurements from this machine

Time to first sample (6 runs):

| direction | runs |
|---|---|
| down | 3.13s, 2.95s, 2.98s |
| up   | 2.96s, 4.49s, 2.98s |

The dominant and most variable term is the endpoint fetch. Five consecutive
calls to `api.fast.com`:

```
1.01s  1.38s  0.89s  4.71s  1.77s
```

So a typical run leaves ~2s of measuring inside the 5s window, and a slow
endpoint fetch leaves none — which is when both dials read 0. The link itself
is healthy (~220 Mbit/s down, ~66 Mbit/s up), and running the helper directly
from a shell produces correct values throughout.

## Suggested fix

Start the measurement window on the **first sample** rather than at process
launch, and keep a longer guard so a genuinely wedged run still gives up:

```diff
+  property bool sampleSeen: false
+
   function updateSpeedTestLine(line) {
     var value = parseFloat(line)
     if (!isFinite(value) || value < 0) return
 
+    if (!sampleSeen) {
+      sampleSeen = true
+      warmupTimer.stop()
+      phaseTimer.restart()
+    }
+
     if (phase === "down") downloadMbps = String(value)
     else if (phase === "up") uploadMbps = String(value)
   }
 
   function startPhase(nextPhase) {
     ...
     speedTestProc.running = true
-    phaseTimer.restart()
+    sampleSeen = false
+    warmupTimer.restart()
   }
+
+  Timer {
+    id: warmupTimer
+    interval: 20000
+    repeat: false
+    onTriggered: root.stopPhase()
+  }
```

`warmupTimer` also needs stopping alongside `phaseTimer` in `close()`,
`stopPhase()` and `onExited`.

Running this locally, each direction now gets a full 5 seconds of actual
traffic and both dials populate reliably:

```
startPhase down
first-sample phase=down val=224     (4.0s after launch)
stopPhase   phase=down              (5.0s of measurement)
startPhase up
first-sample phase=up   val=66      (3.6s after launch)
stopPhase   phase=up                (5.0s of measurement)
```

An alternative worth considering is having `omarchy-network-speedtest` print a
`0` sample (or a ready marker) as soon as its workers are up, so the panel can
distinguish "warming up" from "no data" without a timer change.

## System details

- Omarchy `4.0.4-1`
- Kernel `7.2.5-3-omarchy`, Hyprland `v0.56.2`
- AMD Ryzen 7 7735HS / Radeon 680M (Rembrandt)
- Wi-Fi (`wlp2s0`), connection healthy and not rate-limited