## Summary

`o.launch(command)` / `o.launch_on_start(command)` in `default/hypr/helpers.lua` prefix every command with `uwsm-app --`:

```lua
function o.launch(command)
  return "uwsm-app -- " .. command
end
```

This breaks Hyprland's standard exec-rule bracket syntax (`[workspace N silent] command`, `[float]`, etc. — https://wiki.hypr.land/Configuring/Dispatchers/#exec) when used inside these helpers, because `uwsm-app` does its own argv parsing and tries to look up `[workspace` as a literal executable name instead of passing the bracketed prefix through to Hyprland's exec dispatcher.

## Repro

On a stock Omarchy Lua-config install (Hyprland 0.56.2):

```
$ uwsm-app -- '[workspace 4 silent] foot'
Error: Command not found: "[workspace 4 silent] foot"
```

Confirmed via `journalctl --user`:

```
uwsm_app-daemon[...]: received: app -- '[workspace' 4 'silent]' foot
uwsm_app-daemon[...]: sent: error 'Error: Command not found: "[workspace"' 1
```

By contrast, calling `hl.exec_cmd` directly (bypassing `o.launch`/the `uwsm-app --` wrapper) works correctly:

```
$ hyprctl eval 'hl.exec_cmd("[workspace 3 silent] foot")'
ok
# foot lands on workspace 3, confirmed via hyprctl clients -j
```

So the bracket syntax itself is fine at the Hyprland/`hl.exec_cmd` layer — it's specifically the `uwsm-app --` wrapping in `o.launch()`/`o.launch_on_start()` that swallows it.

## Impact

Anyone writing `~/.config/hypr/autostart.lua` and reaching for the classic Hyprland `o.launch_on_start("[workspace 2 silent] some-app")` pattern (e.g. from prior hyprlang experience, or Hyprland's own docs) gets a silent no-op — no window ever appears, and there's no obvious error surfaced to the user (it only shows up in `journalctl --user`). The workaround is to skip `o.launch_on_start` for such commands and instead persist a class-based `o.window(class, { workspace = "N silent" })` rule in `hyprland.lua`, but that's non-obvious and workspace-pins by class rather than per-launch.

## Suggested fix

Either:
- Have `o.launch`/`o.launch_on_start` detect a leading `[...]` bracket prefix and keep it outside the `uwsm-app --` wrapping (e.g. `[workspace 2 silent] uwsm-app -- some-app`), or
- Document in the autostart section of the manual that bracket exec-rule syntax doesn't work through these helpers, and that a persistent `o.window` class rule is the supported way to pin a launched app's workspace.

Happy to help test a fix if useful.