Run 1Password under XWayland at the display scale so its authorization prompt fits

[brentkearney]

Closes #681

What changes

• bin/omarchy-launch-1password starts 1Password with --ozone-platform=x11 --force-device-scale-factor=<scale> and passes its own arguments through. It still opens the installer when 1Password is missing.
• default/applications/1password.desktop is a per-user desktop entry with Exec=omarchy-launch-1password %U, so app launchers and the onepassword:// URL handler take the same path as the Super + Shift + / binding and the menu.
• install/user/1password.sh installs that entry to ~/.local/share/applications/. It runs during fresh user setup (1Password ships by default on Apple Silicon, and provisioning marks migrations complete), from omarchy-install-service-1password, and from migration 1790792558.sh for existing installs. It replaces entries that start 1Password directly (the tarball's own copy, or the copy whose executable was swapped for the /usr/local/bin/1password software-GL wrapper) and leaves symlinks and entries with custom commands alone.
• omarchy-install-service-1password opens 1Password through the launcher after installing.
• omarchy-remove-service-1password removes the launcher entry. A custom entry is left in place.

How the scale is chosen

• If hyprctl getoption xwayland:force_zero_scaling reports it enabled (the fork default in default/hypr/envs.lua), Hyprland doesn't scale X11 clients, so 1Password has to scale itself. The factor is the focused monitor's scale from hyprctl monitors -j, passed through unrounded (for example 2 or 1.666667).
• If force_zero_scaling is off, Hyprland scales X11 clients itself, so the factor is 1. A higher factor would be applied twice.
• If hyprctl can't answer, or returns no usable scale for the focused monitor, the factor is 1. At factor 1 the prompt can look small on a HiDPI display, but its whole content fits in the window.
• If DISPLAY is unset (XWayland disabled), 1Password starts natively on Wayland as before, since there is no X server to use.

The launcher calls 1password from PATH, so the software-GL wrapper at /usr/local/bin/1password still adds its flags when there's no render GPU.

Why a Mac-specific fix

• Upstream Omarchy pins --force-device-scale-factor=1 in its launcher and in the x86 1password package's desktop entry. On aarch64 there's no package: omarchy-install-1password installs the official arm64 tarball, whose desktop entry has no flags, so the package pin never reaches Omarchy Mac. The fork's launcher has also diverged from upstream and passes no flags.
• The native-Wayland fixes upstream only work for the collapsed prompt. On a MacBook running this fork (display scale 2, GNOME text-scaling-factor 1.1818), both were tried natively on Wayland:
  • --force-device-scale-factor=1 (upstream's launcher): the first view fits. Expanding the request details pushes the buttons below the window edge with no scrolling, and the window stays at 400x370.
  • GSETTINGS_BACKEND=memory (omacom/omarchy#8575): same result. The first view fits, the expanded details push the buttons out of view, and the window stays at 400x370.
• Under XWayland the prompt can resize. With --ozone-platform=x11 --force-device-scale-factor=2 the main window was sharp and normal-sized. The prompt opened at 400x370 and grew to 400x459 when the details were expanded. The buttons stayed visible and Authorize worked.
• xwayland:force_zero_scaling = true is the fork default, so XWayland renders clients at scale 1. The factor has to match the monitor scale, otherwise 1Password comes out tiny on a Retina display.
• ELECTRON_OZONE_PLATFORM_HINT=x11 has no effect on this 1Password build. Only the --ozone-platform=x11 command-line flag switches it, which is why the launcher and desktop entry pass flags instead of setting environment variables.

Related upstream reports: omacom/omarchy#8574, omacom/omarchy#9904, omacom/omarchy#12228, omacom/omarchy#8575.

Related open PRs in this fork

• #349 (software GL wrapper): its changes already reached quattro through #377. This PR builds on that work: the launcher calls the /usr/local/bin/1password wrapper, and the wrapper's desktop repair (omarchy-cmd-desktop-exec-repair) doesn't recognize omarchy-launch-1password as an executable to rewrite, so it leaves the new entry alone. A test covers that interaction.
• #294 (browser-extension unlock) only changes bin/omarchy-install-1password, which this PR doesn't touch. #294 and #349 already conflict with quattro, and this branch adds no new conflicts.

Known limitations

• Off-center prompt: under XWayland the authorization prompt opens off-center, with its top-left corner about 25% across and down the screen. A static Hyprland center = true window rule doesn't affect it. This PR doesn't fix that issue.
• One scale per launch: the scale is read from the focused monitor when 1Password starts. On a multi-monitor setup with different scales, 1Password keeps that scale when its windows are on another monitor, until it's restarted.
• Start at login is not covered: 1Password's own "Start at login" setting writes ~/.config/autostart/1password.desktop, and 1Password rewrites that file itself. Omarchy doesn't control that entry, so an autostarted 1Password still runs natively on Wayland, with the clipped prompt.
• Takes effect on next start: an instance that's already running keeps its old flags until 1Password is quit and started again. The migration doesn't restart it.
• Tested on Apple Silicon only: the launcher change isn't gated by architecture, so fork installs on x86 would also run 1Password under XWayland, but that wasn't tested.

Testing

Manual, on a MacBook running this fork: Hyprland 0.56.2 with the Lua config, 1Password 8.12.0 arm64 tarball, 3456x2234 display at scale 2, GNOME text-scaling-factor 1.1818, force_zero_scaling enabled.

• Stock fork (native Wayland, no flags): the prompt is fixed at about 400x370, with the title, request text and Authorize button clipped.
• --ozone-platform=x11 --force-device-scale-factor=2: the prompt grows from 400x370 to 400x459 when the details are expanded. The buttons stay visible and Authorize works.
• Against the live compositor, the launcher's scale lookup returned 2, and the launcher (with setsid stubbed) built uwsm-app -- 1password --ozone-platform=x11 --force-device-scale-factor=2 onepassword://x.
• desktop-file-validate default/applications/1password.desktop passes.

Automated:

• test/shell.d/launch-1password-test.sh (8 checks): the focused monitor's scale is used when an unfocused monitor is listed first, fractional scales pass through, the factor is 1 when force_zero_scaling is off, when hyprctl fails or when the scale is missing, 1Password starts natively without DISPLAY, URL arguments containing spaces pass through intact, and the installer still opens when 1Password is missing.
• test/shell.d/1password-desktop-test.sh (7 checks): the entry passes %U to the launcher and claims onepassword://. The migration does nothing without 1Password, installs the entry and is idempotent, replaces the tarball, wrapper and pinned entries, and preserves custom commands and symlinks. The software-GL desktop repair leaves the new entry untouched, and removal deletes only the launcher entry.
• ./test/all: test/cli passes. test/shell passes 291 of 297 files. The 6 failing files fail identically on unmodified quattro: five need a sibling omarchy-pkgs checkout (config-test, arm-channel-staging-test, package-build-contract-test, settings-package-units-test, unowned-system-paths-test), and launch-about-test ("a roomy window animates") depends on the live session.
• bin/omarchy commands --check passes (472 commands), and every bin/omarchy-* passes the syntax check.