Recognize Ecosia as a Chromium-family browser in omarchy-launch-webapp

[mattlibera]

Problem

omarchy-launch-webapp whitelists a fixed set of Chromium-family default-browser desktop ids and falls back to a hardcoded chromium.desktop for anything not on the list:

case $browser in
google-chrome* | brave* | microsoft-edge* | opera* | vivaldi* | helium*) ;;
*) browser="chromium.desktop" ;;
esac

Ecosia's default-browser id (org.ecosia.Browser.desktop) isn't on that list, so it silently falls into the chromium.desktop branch. Every web app launch — including protocol-handler launches like Zoom's omarchy-webapp-handler-zoom — then opens in a separate, unauthenticated Chromium profile instead of the user's real, signed-in Ecosia profile. From the user's perspective, the web app "forgets" who they are and any state (e.g. a partially-typed meeting number) on every single launch, because it isn't actually their browser.

Ecosia is Chromium-based (packaged in the AUR as ecosia-browser-bin, currently tracking Chromium 152.x) and supports --app mode exactly like the browsers already on this list, so it belongs in the same bucket as e.g. Helium (#3225).

Fix

Add org.ecosia.Browser* | ecosia* to the recognized case, matching both the desktop id xdg-settings reports and the raw exec name, the same pattern already used for the other entries.

Testing

• Added test/shell.d/launch-webapp-browser-test.sh, covering:
  • Ecosia as the default browser resolves to the Ecosia binary with --app=<url> instead of falling back to chromium.desktop.
  • An unrecognized browser id still falls back to chromium.desktop (existing behavior preserved).
• ./test/cli passes fully.
• ./test/shell: 52-53 files fail identically with and without this change on this sandbox (no compositor/hardware available), confirming they're pre-existing environment-dependent failures unrelated to this diff.