### What happened

A notification whose icon arrives via the **`image-path` hint** as a *themed icon name* renders Qt's magenta/black missing-texture placeholder in the icon slot.

This is the path `notify-send -i <name>` takes: libnotify puts the name in the `image-path` hint and leaves `app_icon` empty, so it affects any sender using `notify-send` with a themed name.

### Steps to reproduce

```bash
notify-send -i definitely-not-an-installed-icon "Notification icon test" "Icon name is not in the icon theme"
```

### Expected

The icon slot is hidden, exactly as `shell/plugins/notifications/components/NotificationCard.qml:116-118` intends:

> Hide the slot when the icon failed to resolve (themed-icon name not in the user's icon theme) AND we don't have a glyph fallback — prevents rendering Qt's pink broken-image placeholder.

### Actual

A magenta/black checkerboard is drawn in the icon slot.

### Cause

`NotificationCard.qml:39`:

```qml
readonly property string smallIconSource: image.length > 0 ? image : iconSource(appIcon)
```

`iconSource()` (line 58) is what resolves themed names and check-guards them:

```qml
function iconSource(icon) {
  var value = String(icon || "")
  if (value.length === 0) return ""
  if (value.indexOf("file://") === 0 || value.indexOf("image://") === 0) return value
  if (value.charAt(0) === "/") return Util.fileUrl(value)
  return Quickshell.iconPath(value, true)   // check flag -> "" when missing
}
```

…but it is only applied to `appIcon`. `image` goes straight to `Image.source`, so a bare themed name is treated as a relative URL, fails to load, and Qt paints its placeholder. The slot's visibility guard doesn't suppress it because `hasSmallIcon` is true (`image.length > 0`).

Per the [Desktop Notifications Specification](https://specifications.freedesktop.org/notification-spec/latest/hints.html), `image-path` is *"a URI … or a name in a freedesktop.org-compliant icon theme"* — so it needs the same resolution as `app_icon`.

Confirmed the hint with `dbus-monitor`:

```
method call ... member=Notify
   string "notify-send"
   uint32 0
   string ""                     <- app_icon is empty
   string "DBUS probe"
   string "body"
   array [ ]
   array [
      dict entry(
         string "image-path"
         variant    string "definitely-not-an-installed-icon"
      )
      ...
   ]
```

In isolation `Quickshell.iconPath("definitely-not-an-installed-icon", true)` correctly returns `""`, so routing `image` through `iconSource()` looks sufficient:

```qml
readonly property string smallIconSource: image.length > 0 ? iconSource(image) : iconSource(appIcon)
```

### Also observed — same symptom, different trigger

A bare **`app_icon`** name also produced the placeholder when the name was absent from a stale `/usr/share/icons/hicolor/icon-theme.cache`, even though the PNGs were on disk. Concretely: Ghostty relays terminal notifications tagged `app_icon=com.mitchellh.ghostty`, and every such toast (Claude Code's among them) showed the checkerboard. `pkexec gtk-update-icon-cache -f -t /usr/share/icons/hicolor` fixed that case.

The cache went stale because Arch's `gtk-update-icon-cache.hook` triggers on `usr/share/icons/*/` but excludes `usr/share/icons/*/?*`, so it never fires when a package adds icons into an existing theme tree. That part is not an Omarchy bug — but the placeholder rendering on an unresolvable `app_icon` name is the same guard failing, and I could not fully isolate why `iconPath`'s check flag didn't suppress it in that state. Flagging it in case the fix should also harden the `appIcon` branch.

### System

| | |
|---|---|
| Omarchy | 4.0.2-1 |
| Quickshell | 0.3.1-1 (Arch) |
| qt6-base | 6.11.2-2 |
| CPU | Intel Core Ultra 9 185H |
| GPU | Intel Arc (Meteor Lake-P) + NVIDIA RTX 4070 Max-Q |
| Icon theme | Yaru-sage-dark |
| Display scale | 2 |