Browser-unlock popup renders an oversized layout inside an undersized window under Wayland fractional scaling

## Environment
- 1Password for Linux 8.12.34-34 (Arch, native Wayland — not XWayland)
- Compositor: Hyprland 0.56.2
- Display: 3840x2160 @ 60Hz, **fractional scale 1.6** (logical desktop 2400x1350)
- Browser: Chromium 151.0.7922.173

## Summary
When 1Password is asked to unlock from the browser extension, the unlock popup
opens as a 402x371 (logical px) window, but its UI is laid out for a viewport of
roughly 643x594 CSS px — exactly 402x371 x 1.6, the display scale. The result is
a desktop-sized layout painted into a small window, so the password field is
clipped and cannot be fully seen or comfortably typed into.

## Steps to reproduce
1. Run a Wayland compositor with a fractional display scale (1.6 here).
2. Start 1Password (locked).
3. Trigger unlock from the browser extension.

## Observed
- The popup (window tx371 logical px.
- Its content is laid out for ~643x594 CSS px and is therefore clipped.
- 402 x 1.6 = 643.2 ae viewport is thewindow size
  multiplied by the dhing it.

## Expected
The popup's layout viewport should match its actual window size, so the
whole
unlock form is visible.

## The popup is size-pinned by the app
This is not something
- A compositor `resizewindowpixel` on the popup returns `ok` and has
**no
  effect** — the window stays 402x371.
- A compositor size rnored for roughly100ms and
  then overridden by
- The same compositor resize on 1Password's **main** window works
normally
  (875x600 -> 784x500, clamped at the app's 784px minimum width).

## The main window is not affected
`~/.config/1Password/rrect logicalcoordinates:
`bounds 1030x663` aga`. Only thebrowser-unlock
popup shows the misma
                                                                        ## Workaround (and th
Launching with Chromium's device-scale override fixes the layout:       
    /opt/1Password/1password --force-device-scale-factor=1              
With this flag the popup window size is **unchanged** (still 402x371),  but the
UI now lays out correctly for that size and the password field is fully visible.
That the fix is a scale-factor override, with no change in window geometry,
points at the popup's viewport being derived with the display scale     applied
where it should not be.                                                 
Downside of the workaround: at scale factor 1 the app renders at 1x and the
compositor upscales by 1.6, so rendering is softer than native.