Some tests fail on 24" iMac due to -Dsun.java2d.uiScale=2

A small number (approx 12) of headful tests always fail or in a couple of cases just "often fail" on some new Apple Silicon imacs.
The root cause is possibly an Apple bug since although there's various scale transforms happening to the screen and from the screen I am not sure why it would cause the issue seen here.

It appears that these all use Robot.getPixelColor() - by no means just these tests do - many do - but these seem susceptible.
Digging into one case - javax/swing/plaf/nimbus/TestNimbusBGColor.java - the expected pixel color was 0x00ff0000 - ie pure red
but we got 0x00ff0001 - a very slight inaccuracy. The correct sRGB color profile was set on the monitor - not the default one
of imac - but one we need to set to ensure that the pixels read back from the display are the same as the ones we drew.

Java2D is using uiScale=2 for all windows on this imac display. It appears that when we retrieve a single pixel,
which is actually a 2x2 rect scaled down to one user space pixel - some tiny inaccuracy is creeping in.
But this isn't in JDK code - it is in the Apple API calls we are making in CRobot.m
the JNI method is Java_sun_lwawt_macosx_CRobot_nativeGetScreenPixels - various CoreGraphics APi calls.
So the problem is seen with both Metal & OpenGL since it is entirely separate from them.

If I set -Dsun.java2d.uiScale=1 then the test passes.

Also what is as yet unexplained, is that if I try to capture some larger region of the window - ie
use Robot.createScreenCapture(Rectangle) - which ends up in the same nativeGetScreenPixels call,
then the inaccuracy vanishes. What I mean by this is that a subsequent call to the Robot.getPixelColor() API
has no inaccuracy. Even if the captured region did not include the x/y location to get the single pixel color.
JDK is not doing anything like capturing the whole window or doing caching which might explain it.
I can only assume that requests for an area over some threshold trigger caching by macOS - and
capturing the larger area fixes the inaccuracy.

Another oddity is that these tests - which typically use a primary color such that (eg) the red component of a pixel is 255-
may pass if I specify the imac Color Profile - which says both that the profile is not changing a 100% setting
and also that somehow color profile conversion is implicated .. but we use the same color profile settings
on other systems. Although they are typically non-retina.

However (!) I can't reproduce these failures on the retina of a 2019 16" macbook pro running a very similar version
of macOS 11.5.1 vs 11.5.2 on the imac. Just an oddity of how the scaling works out on a different display .. or
something else ?

For 10/12 of the failing tests switching to uiScale=1 allows them to pass although since
at least one of them want to explicitly use uiScale=2 that probably isn't going to be sufficient

javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java
javax/swing/JTabbedPane/TestBackgroundScrollPolicy.java
javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java
java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java
java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java
java/awt/Window/BackgroundIsNotUpdated/BackgroundIsNotUpdated.java
java/awt/Window/8159168/SetShapeTest.java
java/awt/Paint/PaintNativeOnUpdate.java
javax/swing/plaf/nimbus/TestNimbusBGColor.java
java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java

Also these two still fail - the first still has an inaccuracy issue
java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java

java.lang.RuntimeException:
    DisplayMode(2240 x 1260 x 32bpp x 60)
    Pixel 0: Expected ffffffff, got fffffeff at 0
at CycleDMImage.main(CycleDMImage.java:296)


And the 2nd .. also uses uiScale=2 and needs a bit more investigation
java/awt/image/multiresolution/MultiResolutionJOptionPaneIconTest.java