When calling SetPosition on macOS, the Y coordinate was calculated
using the current window's screen height as the reference, which
produces the wrong NSWindow frame.origin.y when the target position
is on a monitor at a different vertical offset from the primary
screen.

macOS NSWindow coordinates have Y=0 at the bottom-left of the primary
screen (always [[NSScreen screens] firstObject], which is at origin
(0,0)). Both windowGetPosition and windowSetPosition now use the
primary screen's height as the global Y baseline, making get and set
consistent inverses regardless of which screen the window currently
lives on.

Fixes #5117

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: multica-agent <github@multica.ai>

…ed-DPI

Address CodeRabbit and Copilot review: windowGetPosition and
windowSetPosition were using the current window screen's
backingScaleFactor while relying on the primary screen's height for Y.
On mixed-DPI setups this mixes units — e.g. primary at 2x height 800pt
with secondary at 1x produces incorrect scaled values.

Both functions now obtain scale from the primary screen (firstObject)
to match its height reference, making get/set strict inverses in a
consistent "primary-screen physical pixel" coordinate space regardless
of which monitor the window occupies.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: multica-agent <github@multica.ai>

…cal points, Y-down, top-left)

flofreud's review of #5304 (#5117 (comment))
flagged that macOS still exposed three distinct coordinate spaces:

  * GetScreens()      -> NSScreen logical points, Y-up,   bottom-left of primary
  * Position()/Set    -> NSScreen logical points * pSF,   Y-down, top-left of primary
  * RelativePosition  -> NSScreen logical points,         Y-down, top-left of *current* screen

This commit collapses GetScreens() and Position()/SetPosition() into a single
canonical space: logical points, Y-down, with (0,0) at the top-left of the
primary screen. This is the same convention exposed publicly by Electron's
Display.bounds, Win32 MONITORINFO, GTK and the web (window.screenY /
Screen.availTop). Windows + Linux paths in Wails already expose this space,
so the macOS normalisation also makes the three platforms match each other.

Changes in webview_window_darwin.go:

  * windowGetPosition / windowSetPosition drop the `* primaryScale` /
    `/ primaryScale` multiplications. Values are now logical points, not
    "points x primaryScale". The Y flip against primary height stays.

Changes in screen_darwin.go:

  * processScreen flips Y on both `frame` and `visibleFrame` against the
    primary screen's height, so Bounds.Y is the screen's top edge and
    screens above the primary have negative Y. screenmanager's
    getScreenAlignment (which already assumed Y-down) becomes correct for
    macOS.

After this change `SetPosition(s.Bounds.X + dx, s.Bounds.Y + dy)` lands at
the expected offset on any screen, with no scale dance required.

BREAKING: callers that hand-compensated with `* primaryScale` or that
flipped Y against a screen height (e.g. the workaround in #5117) must drop
those conversions. Position()->SetPosition() round-trips are preserved.

A separate, pre-existing inconsistency in RelativePosition() (Get returns
absolute X, Set treats X as screen-relative) was filed as #5408; the
mixed-DPI Bounds.X/Y scale-factor issue on non-primary screens was filed
as #5409.

Refs #5117