### What happens

On a multi-monitor setup, the `omarchy.system-update` bar widget shows the
"update available" icon on **only one** monitor's bar. Which monitor wins is
non-deterministic — forcing a re-check with
`omarchy-shell omarchy.system-update refresh` reliably moves the icon to the
*other* bar rather than showing it on both.

### What I expected

The update icon appears on every monitor's bar, since the update state is a
property of the system, not of a monitor.

### Root cause

`SystemUpdate.qml` is instantiated per bar, and each instance runs its own
check with `triggeredOnStart: true`:

```qml
Process {
  id: updateProc
  command: ["omarchy-update-available"]
  onExited: function(exitCode) { root.updateAvailable = exitCode === 0 }
}
Timer { interval: 21600000; running: true; repeat: true; triggeredOnStart: true }
visible: updateAvailable
```

`omarchy-update-available` calls `checkupdates`, which uses a single shared
temporary pacman database per user:

```bash
CHECKUPDATES_DB="${TMPDIR:-/tmp}/checkup-db-${UID}/"
trap 'rm -f $CHECKUPDATES_DB/db.lck' INT TERM EXIT
fakeroot -- pacman -Sy --disable-sandbox-filesystem --dbpath "$CHECKUPDATES_DB" ... &> /dev/null
```

With two monitors the two instances invoke this simultaneously and contend on
the pacman lock. The loser's `pacman -Sy` fails, the failure is swallowed by
`&> /dev/null`, its `pacman -Qu` therefore returns nothing, and
`omarchy-update-available` prints "Omarchy is up to date" and exits 1 — so that
bar sets `visible: false`. The `trap` compounds it: whichever invocation exits
first deletes `db.lck` out from under the one still running.

### Steps to reproduce

1. Two or more monitors, each with a bar.
2. Have a pending Omarchy package update.
3. Restart the shell (or run `omarchy-shell omarchy.system-update refresh`).
4. The icon appears on exactly one bar.

Reproducible directly, without the shell, by running two checks concurrently:

```console
$ omarchy-update-available & omarchy-update-available & wait
omarchy 4.0.2-1 -> 4.0.3-1      # exit 0
Omarchy is up to date           # exit 1   <-- wrong
```

Run sequentially, the same command is consistently correct (3/3 exit 0), which
confirms contention rather than a flaky check.

### Suggested fix

Serialize the check — e.g. wrap the `checkupdates` call in
`omarchy-update-available` with `flock` on a per-user lock file so concurrent
callers queue instead of racing. That fixes every caller at once rather than
only the widget. Alternatively, have a single shared poller publish one result
to all bar instances, which would also drop N redundant `pacman -Sy` calls per
refresh on multi-monitor systems.

A related smaller issue: `omarchy-update-available` cannot distinguish
"no updates" from "the check failed", because `checkupdates` failures are
discarded. Treating a failed check as "up to date" is what makes this
user-visible.

### System details

| | |
|---|---|
| Omarchy | 4.0.2-1 |
| Kernel | 7.1.9-arch1-2 |
| Hyprland | 0.56.2 |
| CPU | Intel Core i5-7400 |
| GPU | NVIDIA GP104 [GeForce GTX 1070] |
| Monitors | 2 |
| pacman-contrib | 1.13.1-1 |