## What happened

The app-launch feedback toast (e.g. "Launching Files…") stayed on screen indefinitely instead of auto-dismissing, even though the launched app (Nautilus) started successfully in the background and its window opened normally.

## Root cause

In `/usr/share/omarchy/shell/services/AppLibrary.qml`, `beginLaunchFeedback()` restarts both the `launchDelay` (2s) and `launchTimeout` (15s safety-net) timers on every invocation:

```qml
function beginLaunchFeedback(name) {
  root.launchSerial++
  root.launchToplevelCount = root.toplevelCount()
  root.launchActiveToplevel = ToplevelManager.activeToplevel
  root.launchOsdMessage = "Launching " + String(name || "application") + "…"
  launchDelay.restart()
  launchTimeout.restart()
}
```

If the launcher is triggered again (e.g. the user, unsure whether the first press registered, presses the Files keybinding/menu item a second time) before the toast has resolved, `launchTimeout.restart()` pushes the 15s safety-net back out each time. The toast can then persist far longer than 15s — in my case it was stuck until manually cleared, well after the app's window had already opened.

## Expected behavior

The safety-net timeout should still fire (or the feedback should resolve) even when the launcher is retriggered, so the toast can't outlive its own timeout window indefinitely.

## Steps to reproduce

1. Trigger an app launch that shows the launch feedback toast (e.g. `omarchy launch nautilus`, or Super+E / the Files entry in the app menu).
2. Before the toast resolves, trigger the same launch again (or a couple more times in quick succession).
3. Observe the "Launching …" toast can remain stuck on screen well past the intended 15s timeout, even after the app's window has opened.

## Workaround

`omarchy-shell osd close` manually dismisses the stuck toast.

## System details

- Omarchy version: 4.0.4-1
- `omarchy debug` is not available as a command in this version (`omarchy commands --all` has no debug entry), so no diagnostic log is attached.