Use a generic icon when webapp favicon lookup fails

[nicknack5050]

When favicon discovery fails, installing a web app currently asks for another icon, and submitting an empty icon (or using a failing explicit icon URL) aborts installation. Use the theme's generic web-browser icon instead so a valid app name and URL are sufficient.

The interactive flow now asks only for name and URL. The CLI also accepts two arguments, while successful automatic downloads, explicit icon names/files, custom Exec commands, and MIME types retain their existing behavior.

Validation: the webapp install, escaping, and name suites pass, including new offline/failing-download cases for interactive installs, omitted icons, and explicit icon URLs. Bash syntax and git diff --check pass.

Full ./test/all: CLI suite passed; 228 of 236 shell test files passed. Failures: bar-icon-geometry, config, launch-about, locate, runtime-smoke, snapper, unowned-system-paths, and update-lock. Bar geometry and About failures were reproduced on clean upstream 31bd80d. Several checks require a sibling omarchy-pkgs checkout absent here. The other failures are reported without attributing a cause; the two branch suites were run concurrently in a live desktop environment. None of the webapp suites failed.

[johnpippett]

The command tests and a live test with real websites gave correct results for the icon change. I have one suggestion about the interactive flow.

Source commit: 60948e6b048acdfba2088219ccbcbdcbc4879213.
Base commit: 31bd80daa4613ffdee995ac27467fce5a2990806.

I did these tests with AI assistance. Codex did the isolated command tests. Claude Code did the live tests. The assistants also prepared this review.

Isolated command tests (September 29). I did 21 command scenarios on each revision in Bubblewrap on Arch Linux. Each scenario used temporary user files and read-only source files. The environment had no network or desktop access. All 42 scenarios gave correct results.

When icon downloads do not supply an image, the proposed command writes Icon=web-browser. The scenarios also included valid downloads, empty responses, partial downloads, HTML responses, icon names, local files, custom commands, MIME types, and cancellation.

The webapp-install-test.sh suite gave seven correct results on the base and ten on the proposed revision. Bash found no syntax errors in the changed scripts.

Live tests with the network (October 9). I ran the unchanged base and head scripts. Each run used a new temporary home folder. All results matched the PR description:

Case	Base	Head
github.com	Launcher with a downloaded icon (120x120 PNG)	Same
example.com, which has no usable icon	Exit status 1, "Failed to download icon", no launcher	Launcher with Icon=web-browser
Host that does not resolve	Exit status 1, no launcher	Launcher with Icon=web-browser
Explicit icon URL that fails	Exit status 1, no launcher	Launcher with Icon=web-browser
No network	Exit status 1, no launcher	Launcher with Icon=web-browser
Explicit icon name (firefox)	Icon=firefox	Same

The proposed command also accepted the two-argument form. desktop-file-validate accepted every launcher. In the Yaru-sage theme, web-browser resolves to the compass icon.

Interactive flow with the real gum prompts. I used a pseudo-terminal and no network, so the icon lookup failed. On the base, the command asks for Icon URL/name>. An empty answer ends with "Failed to download icon" and status 1. The answer firefox creates the launcher. On the head, the command asks only for the name and URL, and it always writes Icon=web-browser.

Suggestion. The Omarchy menu runs omarchy-webapp-install with no arguments in a terminal. On the base, the icon prompt is therefore the only way to give a custom icon from the menu after the icon lookup fails. The head removes it. Consider keeping the prompt and treating an empty answer as "use the generic icon". This fixes the abort and keeps the custom icon option.

I did not test the launched web app or the appearance of the icon in the launcher.