## What happened

Clicking a desktop notification from a Chromium-based web app (installed via `omarchy webapp install`, e.g. MS Teams, Outlook) does not focus the app's window or switch to its workspace. The notification itself displays correctly; only the click-to-focus behavior is broken.

## Expected

Clicking the notification should raise/focus the sending app's window and switch to its workspace, the same way it already works for apps like Slack/Discord that don't register a libnotify `"default"` action.

## Root cause

In `shell/plugins/notifications/Service.qml`, `invokePopupDefault()` (around line 374-396):

```js
var ref = entry && !isRestoredRow(entry) ? liveRefs[entry.originalId] : null
var invoked = false
try {
  if (ref && ref.actions) {
    for (var i = 0; i < ref.actions.length; i++) {
      var action = ref.actions[i]
      if (action && action.identifier === "default") {
        action.invoke()
        invoked = true
        break
      }
    }
  }
} catch (e) {
  console.warn("invoke default failed:", e)
}
// Chat apps (Slack, Discord, Vesktop, etc.) rarely register a "default"
// libnotify action — they just expect clicking the notification to
// focus their window. Fall back to focusing the sending app by class so
// that click-to-jump actually works.
if (!invoked) focusApp(entry)
```

Chromium (with `--enable-features=NativeNotifications`, which `omarchy webapp install`-created launchers commonly use, e.g. the bundled MS Teams entry) registers a `"default"` libnotify action on its notifications. `action.invoke()` here just emits the D-Bus `ActionInvoked` signal back to Chromium — the call itself doesn't throw, so `invoked` becomes `true` even when Chromium's own handling of that action fails to actually raise/focus its window afterward.

Because `invoked` is `true`, the code never falls through to the working fallback, `focusApp()` → `bin/omarchy-hyprland-focus-app`, which does a direct `hyprctl dispatch focuswindow` lookup by window class and reliably works (confirmed manually: `omarchy-hyprland-focus-app teams.microsoft.com` correctly focuses/switches to the Teams window).

Chromium's own window-activation-on-notification-click appears to not request proper Wayland xdg-activation in this setup, so its `"default"` action "succeeds" (no exception) without actually doing anything useful for window focus — the exact failure mode the existing fallback comment describes for Slack/Discord, just reached differently.

## Suggested fix

Treat Chromium-derived senders (`NotificationLogic.isChromiumDerived`, already used elsewhere in this same plugin for body sanitization) as another case that should fall back to `focusApp()`, e.g. by also calling it — or verifying focus actually changed — when the sender is Chromium-derived, rather than trusting `action.invoke()` not throwing as proof the window was raised.

## Steps to reproduce

1. `omarchy webapp install "MS Teams" https://teams.microsoft.com ms-teams "" ""` (or use the built-in launcher) with `--enable-features=NativeNotifications`, or install Outlook similarly.
2. Open the app, let a notification arrive while its window is not focused/on a different workspace.
3. Click the toast notification.
4. Observe: notification dismisses, but the app's window is not focused and the workspace does not change.

## Workaround

A keybinding using `o.bind(..., { webapp = "...", focus = true })` (or equivalently `omarchy-launch-or-focus-webapp`) reliably jumps to the window, since it goes through the same `hyprctl`-based focus path as `focusApp()` rather than depending on Chromium's own activation.

## System details

- Omarchy version: 4.0.1-1
- Hyprland: 0.56.2 (v0.56.2, commit efb5099)
- Chromium: 151.0.7922.173 (Arch Linux package)
- Kernel: Linux 7.1.9-arch1-2
- Session: Wayland (native, not XWayland)