Watch startup replay trips the event-rate budget, leaving the panel stuck on "Live updates paused"

## Summary

The panel header is stuck on **"Live updates paused — HEY live updates paused after too many events"** and never recovers. The watch's startup replay is large enough to exceed the plugin's event-rate budget (`watchEventLimit` 256 per 1000 ms, `Service.qml:75-76`) before `ready` is ever printed, so the plugin kills the watch, restarts it a minute later, replays the same backlog, and trips again. The panel never reaches `live`; only the 10-minute refresh keeps the Imbox current.

## Environment

- Plugin at `492802d` (main as of 2026-09-02); upstream HEAD `10d47d2` does not touch the budget
- HEY CLI 1.4.3 (also reproduced with 1.4.0)
- Omarchy 4.0.3-1
- Account: one HEY account, `--account all`

## What happens

Running the plugin's exact watch command from a terminal:

```
hey --account all watch --events added,updated,deleted,new,resync
```

prints ~950 lines before the `ready` line, every time the process starts (three runs, same result):

| | |
|---|---|
| Lines before `ready` | ~950 (443 added, 350 deleted, 153 updated) |
| Oldest replayed event | 2026-09-03 (11 days back) |
| By box | The Feed 612, Imbox 252, Paper Trail 75, Set Aside 5, Reply Later 2 |
| Arrival, per wall-clock second | 255 / 110 / 585 |
| `ready` printed at | ~3.9 s |

585 lines in one second is more than double `watchEventLimit`, so `watchEvent()` sets `_watchRateLimited`, stops the process (`Service.qml:321`), and `watchExited()` schedules a restart after `watchAbuseRestartMs`. The next start replays the same backlog and trips again, indefinitely. `hey watch` itself is behaving as documented ("the backlog a box's first read carries is not new"); it is only the replay volume that exceeds the plugin's guard.

## Notes toward a fix

- Adding `--since ` to the watch command reduces the replay to a single line in my test, and the plugin already does a full Imbox read on `ready`, so the backlog carries nothing the panel needs.
- Alternatively, exempt lines before the first `ready` from the budget (the guard is meant for a misbehaving live producer, not the documented catch-up), or raise `watchEventLimit`.

Happy to open a PR for whichever approach you prefer.

Start by reading Service.qml around lines 75-76 and 321, then run the documented `hey --account all watch --events added,updated,deleted,new,resync` command to reproduce the startup replay and rate-limit loop. Compare the `--since ` behavior with the `ready` handling; done means the panel reaches `live` and no longer remains stuck on “Live updates paused” while preserving the full Imbox refresh.

Written by the indexing model from the issue text.