Fix macOS Retina startup bugs on 1.21.1 (unsupported-resolution dialog + invisible first-person hand)

[seapancakes1]

Summary

On macOS Retina displays, RenderScale 1.3.5 on the 1.21.1 branch causes two cosmetic-but-disruptive startup bugs:

1. Vanilla MC pops an "unsupported resolution (1708×960)" dialog on launch (1708×960 = 854×480 × 2, the real Retina framebuffer).
2. The first-person hand doesn't render until the window is resized by even one pixel, after which it works fine for the session.

Both have the same root cause and a single load-bearing fix.

Root cause

MixinWindow.scale(int) had:

private int scale(int value) {
    if (CommonClass.getInstance() != null) {
        ...
    } else {
        return 0;   // ← bug
    }
}

The mixin runs from MC's bootstrap path before the loader entrypoint has called CommonClass.init(). During that window, Window.getWidth() and Window.getHeight() mixin-return 0, which propagates into:

• the vanilla "supported resolution" check (which then reports the real GLFW framebuffer size as "unsupported" because MC's internal sizing got desynced),
• the main render target sizing path, leaving mainRenderTarget at 0×0 until a real GLFW framebuffer-resize event fires (the manual one-pixel nudge users do as a workaround).

The same return 0; was changed to return value; on the stonecutter branch in commit 8de1073 ("Better scaling implementation"), but that commit was part of a larger 1.21.5+ GpuTexture rewrite and never landed on the 1.21.1 branch.

Changes (3 files, +14 −5)

1. common/.../mixin/MixinWindow.java — load-bearing fix. return 0; → return value; so callers that hit scale() before CommonClass.init() get a sane value back instead of zeroing out.

2. common/.../CommonClass.java — defense in depth. Wrapped every window.getWidth()/getHeight() in setShouldScale, resize(RenderTarget), and resize(PostChain) with Math.max(1, …) so any latent zero can't recreate a zero-sized target. Also incidentally protects against issue #23 (scale factor 0.0 causing 0×0 windows).

3. common/.../mixin/MixinGameRenderer.java — when the existing 5-frame counter expires, also fire Minecraft.getInstance().resizeDisplay() once. That re-runs MC's full framebuffer-resize chain against the real GLFW size — same chain a real window-drag triggers — to harden against the hand-glitch path on systems where MC sized its mainRenderTarget against a stale 0×0 window before CommonClass.init() ran.

Test plan

Tested by the reporter on macOS 15 / Apple Silicon Retina, MC 1.21.1, NeoForge 21.1.x, RenderScale built from this branch:

• Cold launch — no "unsupported resolution (1708×960)" dialog.
• First-person hand visible from frame 1 in a fresh world load — no manual window nudge required.
• RenderScale config screen (Mod Menu / NeoForge config) still works; rescaling still applies.
• Window resize still fires onResolutionChanged cleanly.

Suggested additional CI / cross-platform checks before merging:

• Build still compiles for both Fabric and NeoForge on the 1.21.1 branch (tested NeoForge locally; Fabric not tested but common/ changes are loader-agnostic).
• Sanity check on Windows/Linux that the Math.max(1, …) clamps don't regress anything (they shouldn't — they only kick in when the existing code would already have been passing 0).

Notes / out of scope

• Does not touch the stonecutter branch — those have the same fix already (8de10736 covered the analogous code on the 1.21.5+ pipeline).
• Does not address open issues 1.21.1 NeoForge key binds #42 (1.21.1 NeoForge keybind), 1.21.1 Invisible with Iris shaders active #47 (1.21.1 Iris invisible blocks), 1.21.1 neoforge sodium 6.0+ makes the screen split on Mac #56 (1.21.1 Sodium 6.0+ split-screen on Mac), or Hand invisible in first person when used alongside Aeronautics (Veil pipeline conflict) #77 (Aeronautics/Veil pipeline conflict). Those are independent.