Use the live Steam UI size instead of hardcoded Deck dimensions

[zomars]

Problem

On anything that isn't Steam Deck hardware, every position except Top Left is wrong. Top Right lands near the middle of the screen, and the bottom positions float somewhere around a third of the way down. Closing the Quick Access menu doesn't correct it.

Cause

util.tsx hardcodes the screen as 854x534, which is the Deck's own UI space:

export const SCREEN_WIDTH = 854;
export const SCREEN_HEIGHT = 534;

On other displays the Steam UI runs at a different logical size. On my Steam Machine driving a 4K TV it's 1348x758 (DPR 2.85). So the layout is computed inside an 854x534 box pinned to the top-left corner of a much larger screen. Top Left is the only position anchored at the origin, which is why it's the only one that looks right.

With size: 0.7, margin: 60 on a 1348-wide screen:

Position	Right edge before	Right edge after	Screen edge
Top Right	794	1288	1288
Bottom Right (bottom)	234	698	698

794 out of 1348 is 59% across, i.e. visually centered.

Fix

Read the size off GamepadUIMainWindowInstance.m_BrowserWindow on each poll and fall back to the Deck constants if it can't be read. The picture keeps its 40%-of-width sizing, so it stays proportional to the Deck's look. Since the size is part of the polled state, a resolution change re-lays-out on its own.

Two smaller bugs surfaced once the dimensions were correct, both fixed here:

The virtual keyboard was always considered visible. Presence of a virtual keyboard navigation tree was used as the signal, but those trees are left behind on the main window after the keyboard closes — I count 13 stale ones on a running session — so !virtualKeyboard was never true and the bottom 240px stayed reserved forever. Now it asks m_VirtualKeyboardManager.IsShowingVirtualKeyboard, and the reserved height scales with the screen.

The QAM's available area used SCREEN_WIDTH - qam.width. That window is often wider than the slice of screen it covers — mine reports x: 1000, width: 855 on a 1348-wide screen — so the subtraction produced a wrong or negative width, and the intersection collapsed to nothing and fell back to fullscreen. Anchoring on qam.x is correct regardless of how wide the window is.

Testing

I don't have a working node toolchain on this machine, so I could not run pnpm build or typecheck this. Please treat the build as unverified.

What I did verify: I applied the equivalent change directly to the built dist/index.js of the installed 1.0.0 plugin, hot-reloaded it, and hooked SetBounds on the pip browser view to record the geometry actually applied. On a 1348x758 UI at size: 0.7, margin: 60, Top Right:

Moment	x	right edge
QAM open	563	940
QAM sliding closed	853	1230
QAM closed	911	1288

1288 is exactly 1348 - 60. The 940 while the QAM is open is also correct — the picture tucks against the menu's left edge (qam.x 1000, minus the margin) instead of being covered, and returns to 1288 when the menu closes.

Only tested on one non-Deck screen size. It would be worth a sanity check on actual Deck hardware, where getScreenSize() should simply return the same 854x534 the constants used to provide, making this a no-op there.